[OpenID] guid openid delegate

[Peter Williams]

I'd avoided doing definitional analysis to date, focusing more on the
"natural" flow of the signals in the messages with a view to
understanding the intent of the various security controls. 

Let me comment on Draft #12 (hopefully usefully) now that I've paid
attention:



A "OP Endpoint URL: 

The URL which accepts OpenID Authentication requests, obtained by
performing discovery on the the User-Supplied Identifier. This value
MUST be an absolute URL."

A1. (double "the" in the v12 text, note)

A2. Unless discovery (via HTML or XRI resolution processes) is
constrained to required to ultimately return an Identifier, the OP
Endpoint URL could be sip:.... for all this definition cares. See B1
below for possible fix

A3. the definition would ideally become unhooked from both solicited
auth and discovery, allowing for its formal involvement in unsolicited
auth. In unsolicited auth, there is no User-Supplied Identifier, of
course, and its not discovery which determine a final value for the OP
Endpoint URL. (And, the OP Endpoint is not an accepting function for an
auth request (by definition of unsolicited auth)). See C1 for "fix".

A4. I think we have to keep OP Endpoint URL in the unsolicited Auth
schema of definitions - as I think an unsolicited Auth with non-positive
assertions is actually allowed: one can send id_res (setupRequired)
inviting the RP to come back to the OP EndPoint URL to have the user
complete the setup-grade GUI.



B "Claimed Identifier: 

An Identifier that the end user claims to own; the overall aim of the
protocol is verifying this claim. The Claimed Identifier is either: 

- The Identifier obtained by normalizing (Normalization) the
User-Supplied Identifier, if it was an URL. 

- The CanonicalID (XRI and the CanonicalID Element), if it was an XRI."




B1. Change  "Identifier obtained by normalizing (Normalization)" to
"Identifier obtained as a result of normalizing (Normalizing) and
performing discovery on"

B2. That B1 re-definition would constrain solicited Auth (with non XRI
Identifier input) so that Claimed ID has to be an Identifier - even if
delegation was used.

B3. To allow a Claimed_Identifier to be a non Identifier or
non-CanonicalID, one could add a third case that allows for "custom
discovery" during discovery, and the discovery associated with
unsolicited Auth/Err

e.g. - any other non-Identifier and non-CanonicalID URI that a discovery
process shall have confirmed as a OpenID Provider (OP) to which the end
user delegates responsibility for asserting a suitable Claimed
Identifier




C. The whole spec including the formal model of its protocol state
descriptions (response to immediate request, response to setup request)
- is highly biased against the very notion of unsolicited auth -
probably for historical reasons.

C1. At this stage, it's really just too late for radical surgery to
"properly" admit the unsolicited auth states, in the protocol state
descriptions. A security section in A.6 might give reader some hints on
one might need to make a very liberal reading to understand what one
should actually do when engaging in unsolicited auth and associated
id_res validation by the RP.




> -----Original Message-----
> From: Johnny Bufu [mailto:johnny at sxip.com]
> Sent: Thursday, September 13, 2007 9:02 AM
> To: Peter Williams
> Cc: general at openid.net
> Subject: Re: [OpenID] guid openid delegate
> 
> 
> On 12-Sep-07, at 3:34 PM, Peter Williams wrote:
> > Nothing in the text of OpenID Auth 2.0 #12 obviously makes a
> > delegate OpenID of the guid form (above) be non-conforming.
> In the Terminology section the "OP-Local Identifier" is defined as an
> "Identifier", which in turn is defined as a HTTP URL or XRI.
> 
> But you're right - the (delegation) flow would work without any
> restriction on the OP-Local Identifier (only the OP needs to make
> sense of it).
> > A Guid URL can then be presented as a Claimed_ID, in
> > checkid_immediate for example.
> Claimed_ID needs to be discoverable, therefore anything else than
> HTTP URLs and XRIs won't work (until discovery is defined for them).
> It could be presented as a delegate / op-local id (openid.identity
> field).
> 
> 
> Johnny