[OpenID] DISCUSSION relating to OpenID Discovery 2.1

Tue Dec 30 15:02:56 UTC 2008

Peter,

Wow!  These are great questions you're bringing up.
See more replies inline....

On Tue, Dec 30, 2008 at 3:25 AM, 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.
>
> Technically, you are correct that an XRDS can be ignored, but I think the
spec is pretty clear that there are only 3 "paths through which to do
discovery": XRDS via XRI; XRDS via URL, or HTML Discovery.   Given that
dictum, it would seem that if the XRDS is to be ignored, it can only be done
so by utilizing HTML based discovery.

>
> 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".
>
> Still, the spec clear that whatever the "user-input" is, it must be
normalized into an Identifier, which is clearly defined in the Terminology
sections to be either a URL or an XRI.

>
>
> 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".
>
>
>
I would argue that if the user "input" doesn't exist, then OpenID cannot be
used -- you can't create an authentication assertion on a non-existent
input.  If I'm correct, then the non-existence of "user input", whatever the
form, necessitates the non-use of OpenID.

Right?

Also, an existing "session" implies an existing user-input, normalized into
an Identifier, because I would assert that you can't have an OpenID Auth
"session" without an Identifier.

> 7.3 appears normative, but absent a single MUST is not mandatory. That is:
> openid discovery is optional.
>
>
>
Even if discovery is optional, you must agree that *if* any sort of
Discovery is going to be utilized in OpenID-land, then it must abide by 7.3,
yes?
Though I would concede that Discovery does appear to be optional -- but only
in the case where the RP already knows the OP Endpoint.

Here's my logic:

   1. Discovery is the process of taking an OpenID Identifier (XRI or URL)
   and determining various things, most importantly is the OP Endpoint.
   2. The only way to determine the OP Endpoint is:
      1. OpenID Discovery (7.3)
      2. Reading an already discovered OpenID endpoint.

If the only way to get an OpenID endpoint is via the above two methods, then
*somebody* has to have done Discovery (per 7.3) in order to populate the
mechanism being used in my number 2.2 above.

To my way of thinking, this should be clarified in OpenID auth 2.1 -- at the
least, if an RP is going to use some non-7.3 mechansim to get an OP Endpoint
URL, then that "mechanism" MUST be populated via traditional Discovery.

Otherwise, if Discovery is optional, then that breaks OpenID Auth (IMHO).
The point of OpenID Auth is the user saying, "I control this identifier",
and "I can prove this by setting up Discovery meta-data that an RP can use
to verify the assertion that I control this URL/XRI".  If Discovery is
optional, then an RP would never be able to "trust" the OpenID assertion.

> 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.
>
>
>
Yes, but 7.3.2 is a subsection of 7.3, which defines the "not if"
possibility, which is HTML Based discovery.

> 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)
>
> My opinion is that if 7.3.3 has an "absence of HTML discovery" state, you
must still fallback on 7.3, which says there are only 3 states to pick
from.  So, if I can only pick 3 states/paths, and I can't pick HTML-Based
Discovery, and I can't pick XRI/XRDS, and I can't pick URL/Yadis, then there
are *no* other valid states to pick from.

Using that logic, there is no legitimate "fourth state" (that being one
which is not defined).  It is defined out of existence by 7.3.

>
>
> 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.
>
>
>
See above.  I'm very confident that *if* Discovery is to be performed, then
it must be done via one of the three paths in 7.3.

I'm less confident about Discovery not being optional since the wording is
unclear, but I think the intent was for Discovery to be non-optional (keep
in mind that mandated Discovery could still allow an RP use a lookup table,
or some other mechanism, so long as the lookup table is initially populated
via 7.3 Discovery).

>
>
>
>
>
>
>
>
>
>
> *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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081230/075560f0/attachment-0002.htm>