<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText73179 dir=ltr>
<DIV dir=ltr> If we put the topic in the form of formal committee questions, they might be:-</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>1. what does delegation mean in the context of user-controlled metadata(s)</DIV>
<DIV dir=ltr>2. what does delegation mean in the context of delegation of authority,, in the XRI variant of OpenIDs</DIV>
<DIV dir=ltr>3. what does delegation mean in the context of control over related DNS name spaces, in the HTTP variety of OpenIDs</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>I would weakly argue that there is also a fouth distinct question:</DIV>
<DIV dir=ltr>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>4. what does delegation mean in the context of the non-standardized use of both DNS and PKI controls in the HTTPS variety of OpenIDs (HXRIs leveraging TLS, and https URLs leveraging classical SSL2-era controls).</DIV></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Reviewing those question, now, I'm going to make a VERY bold assertion that, through the formal study of XRDs and XRI resolution by OASIS of HXRIs, the overlapping issues in questions 1, 2 and 4 are reasonably well understood - at least by a 2 or 3 experts in secure name/authority resolution. Question 3 is an original topic of investigation in only as much that Noah's rendition forced out into the open a particular interaction of authority entities: what role (trusted) DNS might be playing in URL redirects.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>What makes the overall topic so heated is that is nicely touches on the blue fly paper of what is so different about OpenID2 from other rival SSO technologies: the movement is actually addressing the spectrum of control and authority issues suited to a wide area networks ... rather than focussing merely on those needs faced by n private federations. In wide area environments, the issues of control and authority display different dynamics to private communities -- and have distinct requirements. Its also a fun community, as its mostly driven by practical adoption and learned feedback, like many good dynamic (crypto) systems.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>I'm very hopeful for OpenID, because its addresses the hard issues without TOO much dogma. I feel we are at similar junction on the issues of authority and control to that which the deployers of the actual (vs paper ) Internet PKI faced. We will surely now get to see which way folks go and which models the standards embed: authoritarian and controlling, or liberating and linking. If the community is mature enough, standard practice using one software set will allow for both extremes during deployment, just as we managed to achieve for the https world.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> Andy Powell<BR><B>Sent:</B> Sat 3/29/2008 7:47 AM<BR><B>To:</B> david@sixapart.com; OpenID List<BR><B>Subject:</B> Re: [OpenID] The 3xx Redirect Debate<BR></FONT><BR></DIV></DIV>
<DIV><PRE style="WORD-WRAP: break-word">David,
firstly, thanks for the useful summary.
Secondly, I hope that by saying:
> I don't have a clear answer, but I do agree that a future
> revision of OpenID Authentication should spell out clearly
> what to do with these various 3xx codes.
I hope you intended to mean "... should spell out clearly what to do
with these various 3xx codes and should interpret them in line with the
underlying HTTP specs".
Is that what you meant? Or are you not willing to go that far
currently?
I think it is very important that OpenID does not work against the
underlying HTTP specs and that getting this right now is more important
than short-term backwards compatability.
Andy
--
Head of Development, Eduserv Foundation
http://www.eduserv.org.uk/foundation/
http://efoundations.typepad.com/
andy.powell@eduserv.org.uk
+44 (0)1225 474319
> -----Original Message-----
> From: general-bounces@openid.net
> [mailto:general-bounces@openid.net] On Behalf Of David Recordon
> Sent: 29 March 2008 08:20
> To: OpenID List
> Subject: [OpenID] The 3xx Redirect Debate
>
> Wow! Just got done reading the threads both on this list and
> the specs list. Certainly a lot of passion in the discussion
> and good points being made all the way around. It was a
> little disheartening to see how brusk it got at times
> (arguing about what mailing list to use wasn't really moving
> the discussion forward). I'm sending this to general@openid.net
> (and will forward a copy to specs@openid.net) since the
> majority of the discussion took place on general, even though
> it was probably better suited for specs. That said, let me
> see if I can help provide a few clarifying thoughts.
>
> Completely ignoring technology for a moment, Noah's use case
> of being able to enter his domain and have it be displayed /
> treated as his OpenID at a Relying Party while having a
> browser redirect to /about/ for normal people seems quite
> reasonable. I have a gut feeling that this is a relatively
> rare practice (guessing most people don't think about doing
> it), but from a user experience perspective I like it.
>
> From a technology perspective, as the discussion very
> clearly showed, making this work with some form of
> predictable backwards compatibility isn't easy. With that in
> mind, the number of OpenIDs that currently issue a 303
> redirect is probably fairly small since I would imagine that
> the majority of people don't understand the difference
> between 301, 302, and 303. I know it took me re-reading RFC
> 2616 and Wikipedia a few times.
>
> From a historical perspective the original OpenID 1.1 specification
> said:
> > Note that the user can leave off "http://" and the
> trailing "/". A
> > consumer must canonicalize the URL, following redirects
> > and noting the final URL. The final, canonicalized URL is the
> > user's identity URL.
>
> It, and now the 2.0 spec as well, do not differentiated
> between the type of HTTP redirect that is occurring. Rather,
> an OpenID RP following the OpenID specification would follow
> any type of
> redirect(s) (making its own choice of how many is too many as RFC 2616
> infers) and then if successful treat the resulting URL as the
> user's OpenID claimed identifier. It would then perform
> discovery on that
> resulting URL, looking for a provider or delegation information.
> While certainly not to the HTTP spec, I believe the original
> intent was to conflate the various types of redirects into a
> single meaning for OpenID. Is that "right", maybe not, but
> it does make the simple cases simpler.
>
> The largest problem I see is that in the wild there is a lack
> of consistent understanding and behavior around 3xx response codes. A
> 302 is often used when a 301 should be, a 302 is treated as a
> 303, and
> I doubt the difference between a 302 and a 307 is widely
> understood.
> 301, 302, and 307 are clearly pretty similar and I do agree
> that a 303 is designed to be treated a bit differently; "See
> Other" versus talking about something being found, moved, or
> redirected. I could see the case being made that an OpenID
> RP should treat a 301, 302, or
> 307 as a 301 (current behavior of use the final URL after all
> redirects) and then a 303 treated as a different form of
> OpenID delegation. (Since delegation is basically saying
> "I'm URL A, but I can prove I also own URL B which I delegate
> to" which is similar to Noah's use case of "I'm URL A, but
> people should see me at URL B, and URL B delegates to my
> provider.") This would add future support for Noah's use
> case while probably breaking a small number of OpenIDs.
>
> I don't have a clear answer, but I do agree that a future
> revision of OpenID Authentication should spell out clearly
> what to do with these various 3xx codes. I think the first
> step there is some real research into the actual use of 303
> on the web as it might relate to OpenID.
>
> Noah, thanks for bringing this up!
>
> --David
>
> _______________________________________________
> general mailing list
> general@openid.net
> http://openid.net/mailman/listinfo/general
>
_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general
</PRE></DIV></BODY></HTML>