[OpenID] DISCUSSION relating to OpenID Discovery 2.1

[Dirk Balfanz]

On Mon, Dec 29, 2008 at 7:25 PM, Peter Williams <pwilliams at rapattoni.com>wrote:

>  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.
>
>
Think about it from the RP's perspective: you get a (perhaps unsolicited)
auth response, which is essentially a statement from a (self-identified) OP
asserting that a certain browser session is linked to a claimed identity.
How do you decide to trust that statement?

You're right in that discovery may not be the only option to infuse trust
into such a statement - the RP might have a local database of who it trusts
to make which statements. But discovery is certainly _one_ way to gain trust
in the auth statements. So in that sense it is _a_ authorization and control
point (not _the_ authorization and control point).

Having said that, I'm not sure how I feel about David's original ideas. :-)

Dirk.

>
>
>
>
>
>
>
>
>
>
>
>
> *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>
> 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.
>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081230/0b67df94/attachment-0002.htm>