OpenID 1.2 Extensions Proposal
grant at janrain.com
Wed Apr 5 20:48:21 UTC 2006
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.
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">
> 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.
More information about the yadis