[OpenID] DISCUSSION relating to OpenID Discovery 2.1

Tue Dec 30 19:00:52 UTC 2008

I gave up half way through my careful reply, as it was approaching formatting-incomprehensible ...to the poor reader trying follow it, point by inset counterpoint.

1.is metadata mandatory (XRDS or HTML)? Id claim no, by design concept. My proffer of proof is an example: the op-initiated unsolicited assertion (which has no openid-classical user input stage, and thus no discovery, SAML1-like). The nature of AX update is secondary proffer.

2. Even if metadata via openid discovery is mandatory for an act of interworking, it's not "intended" (read "conceived") to serve as a control framework (for authorization, privileges, permissions, contract bindings,...)

3. Some folk evidently see a cousin of the openid2 XRI name servers (XDI) as the infrastructure in openid's future that is intended to play the role (one day) of a fully-fledged, very well-designed authority-based distributed control framework -representing the large-N OP->SP trust models, the attribute contracts per SP webapp, the EDI-style "interworking agreement", the contract arrangements, the legal terms and conditions... However, XDI is hardly established practice in OpenID world. I'm not sure if there even exists a single production usage! It's obviously R&D. (if anyone can counter this, let me know; I WANT to try it out, to see if/when it will be viable for business use.) XDI may not never come to be adopted in the "finalized specs", if Nat's alternative "CX" regime supplants it (or the highly practical internet-based MPLS-VPNs (per Rapattoni) become the norm for wire-speed trust networking).

4. you say "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 mechanism to get an OP Endpoint URL, then that "mechanism" MUST be populated via traditional Discovery. "

Why! ..is it so important to you? This proposition essentially turns OpeniD2 into Shib. I might as well just use Shib, and get the assurance of properly specified types expressed in a decent type language. OpenId has really intellectually done nothing if all it does it replace XML with name-value pairs, and SAML metadata with XRDS, and one metadata-based control model for protocol orchestration...with another.

But at least you are being direct and honest about the desire. The "advanced" notions that folks settled on 2 years ago clearly need revisiting - to see which work, which got adopted  in practice, which should get dumped, and which get another  try as they are obviously still works-in-progress.

5. I suspect, while focusing on points about metadata/authorization/control, we are really tangentially addressing the bugbear topic of all websso schemes: repurposing, and the desire of the asserting party to  control who can repurpose an assertion (or reuse a AX response). And of course, that goes  to the heart of the current social debate on who controls a users data, the user or the TTP. Once user's own their data, lots of very traditional business models go out of the door. Lots of governance models also get left behind. Ensuring that such "old-model" controls can be overlaid on such as websso (to control downstream actors) has to be expected. So far, the  openid project has not been a foil for shib-like infrastructure governance models (though one can and should overlay those constructs on OpenID, OPTIONALLY, per trust network)

From: David Fuelling [mailto:sappenin at gmail.com]
Sent: Tuesday, December 30, 2008 7:03 AM
To: Peter Williams
Cc: general at openid.net List; specs at openid.net
Subject: Re: [OpenID] DISCUSSION relating to OpenID Discovery 2.1

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<mailto: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:

    *   OpenID Discovery (7.3)
    *   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<mailto:sappenin at gmail.com>]
Sent: Monday, December 29, 2008 10:12 AM
To: Peter Williams
Cc: general at openid.net<mailto: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/20081230/5e75c80b/attachment-0002.htm>