OpenID 1.2 Extensions Proposal

[Johannes Ernst]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060405/2f48c592/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst