[OpenID] DISCUSSION relating to OpenID Discovery 2.1

[Peter Williams]

The following is rather academic. Bear with me; I'm making a not so subtle point.

I don't see anything in openid auth v2 that mandates that the consumer MUST respect the XRDS. That is, if there exists local means to locate the OP, a consumer may vector the user's browser there. There is nothing non-conforming in sending the user to an OP that is missing from the XRDS. Therefore the XRDS is not a control apparatus. In any case the https cert of the endpoint at which the XRDS is located  may not be valid - given validity is a subjective metric of the RP - denying validity to the (unsigned) XRDS on the grounds of lack of assured integrity.

Ok .Why would anyone believe  such a(n academic) claim?

First off, the requirement to display the form to collect the openid is only noted as a SHOULD. That is, per any SHOULD conformance constraint, there exist good reasons to do otherwise. Furthermore, critical failures do not occur merely as a result of following any such (good) reasons. Only in the case of following the SHOULD counsel will there exist a User-Supplied Identifier. Otherwise, there may well exist only "end-user user input".

While 7.2 procedures are uniformly expressed in terms of MUST (and they address any and all "end-user user input") they are contingent of user "input" (which may not exist). A user may have, by way of contrast to "input",  a existing user session (created by means unknown) and the consumer MAY (absent denial) initiate openid auth from that state, for example. This proposition is generally consistent with the notion of "unsolicited"  assertions - which a consumer may legitimately (and outside of OpenID Auth) "induce".

7.3 appears normative, but absent a single MUST is not mandatory. That is: openid discovery is optional.

7.3.2 has a clear IF... which implies that "not if" is a normative possibility. That is:  XRI resolution and YADIS are optional implementation areas.

7.3.3 has states in which absence of an HTML discovery document is ...an entirely "legitimate" state. What happens in that state is not defined (compounded in the case that there has been no use of XRI/YADIS)

I thus fail to find that XRDS/HTML is intended to be an authorization/control framework. If it is supposed to be, its badly specified. I suspect from the phrasing, it supposed to be convenient metadata.






From: David Fuelling [mailto:sappenin at gmail.com]
Sent: Monday, December 29, 2008 10:12 AM
To: Peter Williams
Cc: general at openid.net List
Subject: Re: [OpenID] DISCUSSION relating to OpenID Discovery 2.1

Peter,

Thanks for your input...see my replies inline.

david

On Mon, Dec 29, 2008 at 4:36 PM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>> wrote:

The main problem I have is ...you are changing the character of XRDS (and XRI 2.0 resolution).
Yes, but I'd be open to accomplishing these ideas without doing so.



 In 1, you are turning metadata discovery into a authorization/control framework. Won't be long before you will want a "#include QXRI" line in the XRDS, that imports XRDs from a superior policy authority, and require the XRI client resolver to now to "augment" the XRDs with those from the control authority. If OpenID needs an policy-based authorization framework, let's consider that in its own right (and there is LOTS AND LOTS of previous work to draw on). Let's not break the (nicely working) metadata model, tho.


Well, it already is an authorization/control framework.  The value of the OP endpoint in your XRDS document is what controls what your OP is.  Proposal #1 merely extends this to say that you need 2 OP's instead of one, and possibly only for certain sites.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081229/4705f63b/attachment-0002.htm>