OpenID 1.2 Extensions Proposal

[Grant Monroe]

Jonathan made this point already, but I would like to reiterate it
because I think it is important. Listing protocol dependencies in the
XRDS file is a *bad* idea. First of all, if a relying party is looking
for a service of a particular type, they better well know that what
protocol dependencies there are for that type. Second, users are
destined to screw up the dependencies. Just because I fail to list
openid as a dependency for sreg in my XRDS doesn't mean sreg doesn't
depend on openid.

--
Grant Monroe
JanRain, Inc.

On 4/5/06, Johannes Ernst <jernst+lists.danga.com at netmesh.us> wrote:
> I understand your argument, but let's see where that leads us.
>
> You are proposing to use XRDS Service elements to specify things like
> OpenID SSO, LID SSO and XRI i-SSO, but not dependent extensions of
> those. Then, if an extension A comes around that depends on OpenID,
> you create an element using the <openid:Extension> for A. Presumably,
> you would argue that if, say, there was a LID extension B that
> depended on LID SSO, we'd create a similar new element called
> <lid:Extension> for B.
>
> Did I get this right so far?
>
> But let's assume somebody now extends A with C. Do we get this, then?
>
>    <Service priority="20">
>      <Type>http://openid.net/signon/1.2</Type>
>      <URI>http://www.myopenid.com/server</URI>
>      <openid:Extension>
>        http://openid.net/extensions/A/1.0
>        <A:ChildExtension>
>           http://openid.net/extensions/extensions/C/1.0
>        <A:ChildExtension>
>      </openid:Extension>
>    </Service>
>
> with yet another extension construct, this time specific to A, just
> like the extension mechanism you are proposing is specific to openid.
>
> Is that where you want to take this? Changing the file parser every
> time you want to add an extension?
>
> I don't think this is a hypothetical even now, because if we just use
> your sreg proposal, chances are somebody out there wants to add a new
> data element to the list of supported data elements, and thus creates C.
>
> Also note that this hierarchical scheme does not allow you to say
> "Here is an extension C, and it depends on *both* A and B".
>
> I think you feel uncomfortable just using the plain XRDS file because
> you do not see how you can express "B cannot be used without A" (aka
> "B is an extension of A", or "B depends on A"). What about, then,
> extending XRDS to be able to express those dependencies instead of
> creating a Service-specific extensions mechanism?
>
>
>
>
>
> On Apr 5, 2006, at 9:54, Jonathan Daugherty wrote:
>
> > #   <Service priority="20">
> > #     <Type>http://openid.net/signon/1.2</Type>
> > #     <Type>http://openid.net/extensions/sreg/1.0</Type>
> > #     <URI>http://www.myopenid.com/server</URI>
> > #   </Service>
> >
> > We decided not to do it this way (either with two Types or one per
> > Service) because the extension itself is not a standalone service.  It
> > requires OpenID.  If you want the extension, you can still look for it
> > using whatever normal XRDS-querying API you might have, but it is much
> > clearer to *call* it an extension if it *is* an extension rather than
> > claiming that it's a completely new type of service.
> >
> > --
> >   Jonathan Daugherty
> >   JanRain, Inc.
>
> Johannes Ernst
> NetMesh Inc.
>
>
>
>   http://netmesh.info/jernst
>
>
>
>
>
>
>
>