[OpenID] [LIKELY_SPAM]Re: [LIKELY_SPAM]Re: Problems with delegation and directed identity OPs

[Peter Williams]

More on this topic:

Though in our experiments where an OpenID2 OP fronted a SAML2  sp-initiator entity requiring the IDP to use a persistent format (which passes a SAMl2"masked identity cliam" through to the OpenID RP),I still considered the solution consistent with the definition:

User-Supplied Identifier:
An Identifier that was presented by the end user to the Relying Party, or selected by the user at the OpenID Provider. During the initiation phase of the protocol, an end user may enter either their own Identifier or an OP Identifier. If an OP Identifier is used, the OP may then assist the end user in selecting an Identifier to share with the Relying Party.

The definition requires that the OP assist the _user__select what id to share with the RP. That is the OP has no say, and cannot invent identifiers, during directed identity flow. In our experiment, the user had conformingly and positively _selected_ the id claim value (a smartcard, and its private signing-key); all the SAML2/OP gateway did was mask the value, using a one-way function (that optionally received hashing-contributions from attributes). The RP still has assurance, from protocol conformance, that the value is - unlike a local id - CONTROLLED by the user.

The protocol design has to provide normative assurance that a conforming (non-rogue) OP cannot spoof this "user control" signal. Otherwise, obviously, even a non-rogue OP is just a MITM point.

Obviously determining which OP  is rogue and non rogue lies outside of OpenID specs. RPs may rely on xmldsigs in the discovery response to validate the authority and/or trustworthiness of a given OP to perform directed identity at a given endpoint. The authority comes from the structure of the XRDS bindings (of protocol endpoint to assertion namespace), and the trustworthiness signal comes classically from the cert chain supporting the xmldsig.

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Peter Williams
Sent: Saturday, November 08, 2008 2:29 PM
Cc: OpenID List
Subject: [LIKELY_SPAM]Re: [OpenID] [LIKELY_SPAM]Re: Problems with delegation and directed identity OPs


Resend, with intended addressing.

See end. That claim is formally true, unless the extension is doing its own auth.

Id vote for an openid 2.1 doing openid2 model of delegation more forcefully than before (to prevent version conflicts, like TLS had/has to deal with). Perhaps in an extension, let an openid2 RP interact with an openid1 OP, once its learned (the hardway) to "fallback". This design round, fallback should be supported by an explicit security enforcing function crafted for the fallback security control.

One interesting "alternative" extension "doing auth" would be one that does the saml artifact resolver flow (over the extension, over the openid association, given a saml url bearing the artifact value is a entirely conforming claimedid url).

This would also be a nice act of protocol convergence, where the back channel security that saml2 artifact resolution requires would get all that the core of openid2 libraries bring: xrds metadata, https, discovery, dh associations (and persistent sp-side state management for delegation), xri AND even xri trusted resolution (using saml tokens for communicating a namespace's authority).

.-----Original Message-----
From: Andrew Arnott <andrewarnott at gmail.com>
Sent: Friday, November 07, 2008 10:17 PM
To: Breno de Medeiros <breno at google.com>
Cc: OpenID List <general at openid.net>
Subject: [LIKELY_SPAM]Re: [OpenID] Problems with delegation and directed identity OPs

>From the spec:
Value: (optional) The Claimed Identifier.
"openid.claimed_id" and "openid.identity" SHALL be either both present or both absent. If neither value is present, the assertion is not about an identifier, and will contain other information in its payload, using extensions (Extensions).So you can't include one without the other.  And having neither doesn't provide any authentication at all.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081110/96231c3b/attachment-0001.htm>