[OpenID] Laws of id, openid with ssl

[Peter Williams]

So two issues concern me still on this topic!
 
(1) The control objective expressed in law #4 does not limit the implementing enforcement functions to PPID or its openid equivalent. As it stands, its a general assurance about the scope of identifiers, distinguising between those that are public and those that are not - being essentially user-directed in scope. (It does NOT obviously imply one id per RP, note)
 
(2) did anyone honestly reading the Openid2 spec realize that the function of the OP Identifier mechanism was the same function as: pass a PPID, partly keeping that value secret from the user?
 
If we look around, a wider contextual understanding of PPIDs is expressed at http://www.leastprivilege.com/CardSpacePPIDsAndUniqueIDsMyConclusion.aspx.
 
Now, nothing in the OpenID2 protocol spec would have caused me as an implementor (or as a product evaulator evaluating security claims) to consider that the result of the OP Identifier procedures should be used in this way (for claimed anti-phishing properties) by OpenID2 "applications". 
 
Ok. Som, lets now requote the Law (which is obviously a bad law, seeing as noone can agree what it means, tho this makes it an excellent control objective for security auditors!)

"A universal identity system MUST support both "omnidirectional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles." 

The reason I know I personally wandered into openid2's "discovery" territory phase for an interpretation of "directed identity" rather than focus on the OP Identifier/Local ID line was (a) because openid is relatively (only relatively, note) novel in its use of discovery (NADF X.500 did the same, note, allowing multiple service providers to all portably service a common ENUM, woops, I mean DN, to which a cert was bound), and (b) the law mentions "discovery".

Secondly, it seemed like the point of using a phrase like "thus facilitating discovery" implied omni-id was used during discovery, whereas directed-id would/could be applied during reliance/use/presentation. As discovery is a public act, the idea seemed to be: they didnt want the act of discovery to be have a mandatory, builtin traffic analysis capability, so they wanted to ensure that correlation between discovery phase and reliance phase was "tempered".

Neither of these hints (that I have now learned led me to a completely "wrong" intepretation of the control) have anything obviously to do with OpenID directed-identity or PPIDs. PPID and openid directed-identifies (and law #4) apparently exist to separate RPs (or RP-affiliated reliance communities), not to separate personal informtion flow during discovery from personal information flow during reliance/use!

 

[I have to say, I prefer SAML2's persistent name format combined with SP affiliations, and optionally a wire-encrypted SAML_Subject element assertion. I least I understood those 3 controls and their combinations, after only a couple of readings.]

 

 

________________________________

From: general-bounces at openid.net on behalf of Drummond Reed
Sent: Thu 1/24/2008 6:41 PM
To: 'Martin Atkins'
Cc: 'OpenID List'
Subject: Re: [OpenID] Laws of id, openid with ssl



> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Martin Atkins
> Sent: Thursday, January 24, 2008 4:27 PM
> Cc: 'OpenID List'
> Subject: Re: [OpenID] Laws of id, openid with ssl
>
> Drummond Reed wrote:
> > Peter, just to reinforce Dick's first step below -- in directed
> identity,
> > the user does not give their own public identifier to the RP, only the
> > identifier of their OP. That way the RP knows how to discover the OP's
> XRDS
> > and connect to the service endpoint for the OP's directed identity
> service
> > (<Type>http://specs.openid.net/auth/2.0/identifier_select</Type>).
> >
> > The OP then returns the user's selected identifier (either public or
> private
> > -- user's choice).
> >
>
> I think calling it a "private" identifier is a bit misleading. All
> OpenID identifiers are public.
>
> Perhaps a terms to use would be "obfuscated", "single-use" or "throwaway".

Disagree. A pairwise-unique identifier generated by an OP is not intended to
be public. If it was shared publicly, i.e., could be associated with the
public identifier of the user, it would lose its capability to privately
identify the user's relationship with the RP.

An OP-generated pairwise-unique identifier is the OpenID equivalent of the
PPID ("Private Personal Identifier") in Cardspace.

=Drummond

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general