Subject: [weirds] Auth vs bootstrap

From: Alessandro Vesely <[email-masked]>
Date: Wed, 01 Aug 2012 16:33:22 -0700

Hi,
this is a written version of the triangular paths I came out with
during this morning's session.

The triangle CIR is composed by a client C, who is registered at a
weirds server I that plays the role of an identity provider, and a
target weirds server R, a.k.a. "relaying party" in remote
authentication parlance.

*C queries R identified by I*

This path requires a bootstrap mechanism to locate R, possibly through
some redirection.  At this point OpenID/OAuth is needed in order for R
to collect relevant data from I.

Pros: The bootstrap mechanism works independently of auth.
Cons: The authentication mechanism is not HTTP-native.

*C gets redirection and authentication from I*

This assumes the client is operated by someone who is identified by an
appropriate whois record at I.  It further assumes weirds servers
trust one another.  I identifies C and determines the target server.
It is quite heavy to encode a certificate in a RESTful query, hence I
has to pass a pointer to itself.  R will learn the identity provider
that way.

Pros: The redirector's load is proportional to the number of
      registered users in the corresponding TLD.

As an alternative, small weirds servers may want to directly connect
to R and perform the query on behalf of C.  It is called "mashup" in
web services parlance.  An advantage of such additional work is the
server's ability to monitor not only the query, but also the result R
delivers.  That way, local policies can be tuned taking into account
the symmetrical policies that other TLDs operate.

Pros: HTTP authentication suffices.

*Note*

The above is about authenticated queries only.  What percentage are
they?  Is this split transverse w.r.t. names/numbers?

jm2c

---

From: Arturo Servin <[email-masked]>
Date: Wed, 1 Aug 2012 16:47:36 -0700

I thought that today we dropped bootstrapping and authentication had to be simple.

Did I miss something?

Did I misunderstand something?

as

On 1 Aug 2012, at 16:33, Alessandro Vesely <[email-masked]> wrote:

> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Ray Bellis <[email-masked]>
Date: Thu, 2 Aug 2012 01:10:16 +0000

> Did I misunderstand something?

I thought we concluded yes on simple authentication (for now), but didn't drop bootstrapping...

Ray

---

From: Ray Bellis <[email-masked]>
Date: Thu, 2 Aug 2012 01:24:35 +0000

> target weirds server R, a.k.a. "relaying party" in remote

FWIW, if we redirect a second-level domain (e.g. ".ac.uk") to a third party, we will not want to be involved in _any_ way with authenticating the user to them, nor proxying the query to them.

It'll just be a plain and simple HTTP redirect.

Ray

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Aug 2012 22:57:13 -0700

> I thought we concluded yes on simple authentication (for now), but didn't
This was approximately my understanding as well.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2012 06:22:36 -0000

>This was approximately my understanding as well.

For bootstrapping, I think we agreed it's not an issue for numbers,
since the current approach of starting with the closest RIR is
adequate.  For names we'll need to do something but we'll worry about
it later.

R's,
John

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 2 Aug 2012 07:49:29 -0700

> adequate.  For names we'll need to do something but we'll worry about

Talking only about numbers-bootstrap:

I propose to be very explicit about what 'later' means: after we finished a base spec. 

It seems one of those operational things where a bit of running code might be beneficial before hooking it into protocol.

I am not quite saying that we may want to explicitly recharter when we start working on the bootstrap, but in spirit I am not quite far away from that modus operandus. Base first, bootstrap later, when there is a bit of experience.

I wonder if that reflects the overall sentiment

--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

Science Park 400, 1098 XH Amsterdam, The Netherlands