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

[Peter Williams]

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/20081108/3015997a/attachment-0001.htm>