Re: [xri] <Link> Semantics

[Eran Hammer-Lahav <eran@hueniverse.com>]

Title: Re: [xri] <Link> Semantics

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).

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.

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.

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>
>    <Type>http://specs.openid.net/personal</Type>
>    <Link>
>       <Rel>http://openid.net/signon/1.0</Rel>
>       <URI>https://op.example.com</URI>
>    </Link>
>    <Link>
>       <Rel>http://specs.openid.net/auth/2.0/signon</Rel>
>       <URI>https://op2.example.com</URI>
>       <LocalID>https://user.op2.exampe.com</LocalID>
>    </Link>
> </XRD>
>
> XRD for the https://op.example.com:
>
> <XRD>
>    <Expires></Expires>
>    <Subject>https://op.example.com</Subject>
>    <Type>http://openid.net/extensions/sreg/1.1</Type>
>    <Type>http://specs.openid.net/extensions/pape/1.0</Type>
>   
> <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type>
>    <Link>
>       <Rel>http://openid.net/signon/1.0</Rel>
>       <URI>https://op.example.com/auth</URI>
>    </Link>
> </XRD>
>
> XRD for the https://op2.example.com:
>
> <XRD>
>    <Expires></Expires>
>    <Subject>https://op2.example.com</Subject>
>    <Type>http://openid.net/srv/ax/1.0</Type>
>    <Type>http://specs.openid.net/extensions/pape/1.0</Type>
>   
> <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type>
>    <Link>
>       <Rel>http://specs.openid.net/auth/2.0/signon</Rel>
>       <URI>https://op2.example.com/auth</URI>
>    </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