[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] <Link> Semantics
Eran Hammer-Lahav wrote: > There is no single way to do this. But I strongly believe there are > ways that are more in line with the architecture. OpenID is free to > define relation types that mean “My OpenID 2.0 provider with PAPE > support”, but that is just awful! Its a relation type that only works > for users’ XRD that is also hosted by the IDP (they are using). No argument from me here:) > > The basic question (which is not clear at all) is at what level do > users (and companies) need to delegate their identity services. If > they need to be able to say, my 1.1 provider is Google, but my 2.0 > provider is Yahoo!, the solution below is required. But I just don’t > see this as a valid use case. I’ll go further to say that users should > have little to no direct involvement in influencing IDP selection (if > they have more than one), other than using the XRD priority attribute > feature. Any other IDP property should be left for negotiation between > the RP and IDP. But given that not every 2.0 provider is also a 1.1 provider, I can see the case where I might want to have both a 1.1 provider and a 2.0 provider and they could be different. Albeit not very likely in the currently climate where most users will just use the OpenID provided by the major provider they already use. > > I am also tired of the “extra round trip” argument against the new > architecture. OpenID already has an expensive first-use requirement > with its DH association. RPs should cache IDP XRDs which will allow > them to skip the extra discovery spec 99% of the time (since the > majority of users will always use a small number of providers, in any > given context). RP’s don’t need the user to help them with hints about > the IDP if they can simply learn and cache that information. I wasn't trying to argue for one way or the other, just stating a fact as it seems that these "round-trips" get brought up by the mobile community much more than the web community (as seen by the push within the OAuth IETF charter to consider a direct authentication method; draft-dehora-farrell-oauth-accesstoken-creds-01.txt). However, based on your most resent response to Drummond, if we optimize the purist form for the pragmatic form, then extensions are defined by <Rel> elements which could be included in the <Link> element in the user's XRD. I agree that most users won't see or have control over this data as it will be provisioned by the OP in the user's XRD (in most cases). Thanks, George > > So the basic OpenID XRD-based discovery flow (outlined in my recent > blog post [1]) should go like this: > > The user's XRD looks like this: > > <XRD> > <Subject>http://example.com/joe</Subject> > <Type>http://openid.example.net/type/user</Type> > <Link> > <Rel>http://openid.example.net/rel/provider</Rel> > <URI>http://provider.example.org</URI> > </Link> > </XRD> > > The IDP’s XRD looks like this: > > <XRD> > <Subject>http://provider.example.org</Subject> > <Type>http://openid.example.net/type/provider</Type> > <Link> > <Rel>http://openid.example.net/endpoint/auth/1.1</Rel> > <URI>http://provider.example.org/1.1/signon</URI> > </Link> > <Link> > <Rel>http://openid.example.net/endpoint/auth/2.0</Rel> > <URI>http://provider.example.org/2.0/signon</URI> > </Link> > </XRD> > > And the RP’s XRD looks like this: > > <XRD> > <Subject>http://relayingparty.example.org</Subject> > <Type>http://openid.example.net/type/relay</Type> > <Link> > <Rel>http://openid.example.net/endpoint/callback</Rel> > <URI>http://relayingparty.example.org/openid/callback</URI> > </Link> > </XRD> > > As for where to put extensions, that is based on the extension. More > on that soon. > > EHL > > [1] > http://www.hueniverse.com/hueniverse/2009/03/xrdbased-openid-discovery.html > > > On 3/17/09 5:19 AM, "George Fletcher" <george.fletcher@corp.aol.com> > wrote: > > I see a couple of options... but I'm not sure I've seen any consensus. > The two options I see are to use multiple <Rel> elements or multiple > <Type> elements (or a combination of both). However, this gets to how > much information should be in the XRD associated with the user's > OpenID. > For example, the user's XRD could just point to OpenID provider(s) and > the service reading the XRD would need to fetch the XRD for each OP in > order to determine which services that OP supports. This means extra > fetches but might be the cleanest. This is what is proposed below. > > XRD for the OpenID: > > <XRD> > <Expires></Expires> > <Subject>https://user.op.example.com</Subject> > <https://user.op.example.com%3C/Subject%3E> > <Type>http://specs.openid.net/personal</Type> > <http://specs.openid.net/personal%3C/Type%3E> > <Link> > <Rel>http://openid.net/signon/1.0</Rel> > <http://openid.net/signon/1.0%3C/Rel%3E> > <URI>https://op.example.com</URI> <https://op.example.com%3C/URI%3E> > </Link> > <Link> > <Rel>http://specs.openid.net/auth/2.0/signon</Rel> > <http://specs.openid.net/auth/2.0/signon%3C/Rel%3E> > <URI>https://op2.example.com</URI> <https://op2.example.com%3C/URI%3E> > <LocalID>https://user.op2.exampe.com</LocalID> > <https://user.op2.exampe.com%3C/LocalID%3E> > </Link> > </XRD> > > XRD for the https://op.example.com: > > <XRD> > <Expires></Expires> > <Subject>https://op.example.com</Subject> > <https://op.example.com%3C/Subject%3E> > <Type>http://openid.net/extensions/sreg/1.1</Type> > <http://openid.net/extensions/sreg/1.1%3C/Type%3E> > <Type>http://specs.openid.net/extensions/pape/1.0</Type> > <http://specs.openid.net/extensions/pape/1.0%3C/Type%3E> > > <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type> > <http://schemas.openid.net/pape/policies/2007/06/phishing-resistant%3C/Type%3E> > <Link> > <Rel>http://openid.net/signon/1.0</Rel> > <http://openid.net/signon/1.0%3C/Rel%3E> > <URI>https://op.example.com/auth</URI> > <https://op.example.com/auth%3C/URI%3E> > </Link> > </XRD> > > XRD for the https://op2.example.com: > > <XRD> > <Expires></Expires> > <Subject>https://op2.example.com</Subject> > <https://op2.example.com%3C/Subject%3E> > <Type>http://openid.net/srv/ax/1.0</Type> > <http://openid.net/srv/ax/1.0%3C/Type%3E> > <Type>http://specs.openid.net/extensions/pape/1.0</Type> > <http://specs.openid.net/extensions/pape/1.0%3C/Type%3E> > > <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type> > <http://schemas.openid.net/pape/policies/2007/06/phishing-resistant%3C/Type%3E> > <Link> > <Rel>http://specs.openid.net/auth/2.0/signon</Rel> > <http://specs.openid.net/auth/2.0/signon%3C/Rel%3E> > <URI>https://op2.example.com/auth</URI> > <https://op2.example.com/auth%3C/URI%3E> > </Link> > </XRD> > > Please poke holes:) I'm curious as to whether others were thinking > along > the same lines. I tried to find all the correct <Type> values either > from real XRDS files currently in use and/or the specifications > themselves. Note that I just made up a value for the <Type> in the XRD > for the OpenID. > > Thanks, > George > > Drummond Reed wrote: > > > > Although I'm too tired on a Friday night to try it myself right > now, I > > played briefly with different scenarios for doing this over IM > with Nat > > after yesterday's call. > > > > What I would love is if someone would contribute before the next > > telecon two > > fully-fleshed out example XRDs in the new proposed schema > > (http://wiki.oasis-open.org/xri/XrdOne/XrdSchema) that illustrate the > > following typical OpenID scenario: > > > > 1) An OP user's XRD that references the OP's XRD and includes > links for > > OpenID 1.1, and OpenID 2.0 with SREG and PAPE support. > > > > 2) The OP's XRD that describes the OP's endpoints for both > services above. > > > > These examples would go a long ways towards closing this > question, and > > would > > likely serve double duty because we could use them as the basis for > > examples > > we would use in the XRD 1.0 spec. > > > > If it's easier to just post these examples to the list, I'll > volunteer to > > transcribe them to the wiki. > > > > Thanks, > > > > =Drummond > > > > > -----Original Message----- > > > From: Nat Sakimura [mailto:n-sakimura@nri.co.jp] > > > Sent: Thursday, March 12, 2009 10:18 PM > > > To: XRI TC > > > Subject: [xri] <Link> Semantics > > > > > > Hi. > > > > > > I screwed up the DST that I called in one hour late today... > > > (Hey, it is still the second week of March!) > > > > > > Anyways: > > > > > > From what I heard over a pretty noisy international telephone line, > > > I think I heard something tlike <Link> always represents a > relationship > > > between > > > the resource described by the XRD (identified canonically by the > > > XRD:Subject element) and another target resource. > > > > > > My first question is: Could this target resource be oneself? > > > > > > In case of OpenID, both user and the OP has XRD. > > > User's <Link> elements describes which OP endpoints he wishes > to use. > > > OP needs to express his target endpoint in his XRD somehow. > > > Traditionally, it was done in <Service>. Is it now <Link> that does > > this? > > > > > > If that is true, we now have no <Type> inside <Link>. > > > How do we express that <Link> is representing for example > OpenID 2.0 > > AuthN > > > endpoint? > > > > > > Regards, > > > > > > =nat > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe from this mail list, you must leave the OASIS TC > that > > > generates this mail. Follow this link to all your TCs in OASIS at: > > > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]