[security] Validating openid.identity in authenticationresponses

Manger, James H James.H.Manger at team.telstra.com
Sun Nov 18 22:36:35 UTC 2007


Johnny Bufu gives a reason for directed identity as;
“- user changing their mind at the OP (OP can keep better track of
which identifiers the user presented at each RP)”

This is another good reason for identifying the RP during discovery
so the “name provider” can redirect the user-entered identifier
to the identifier the user presents at this RP.
[http://openid.net/pipermail/specs/2007-October/002007.html]

You can get functionality quite similar to “directed identity”,
but using an extra redirect during discovery, instead of
performing discovery twice (before and after authentication).

Directed identity should be kept, but the RP should also
identify themself during discover.

Add to spec: “The Relying Party MUST include a "From" HTTP header field in each HTTP request made during discovery.”




----------
From: security-bounces at openid.net [mailto:security-bounces at openid.net] On Behalf Of Johnny Bufu
Sent: Saturday, 17 November 2007 5:08 AM
To: david at sixapart.com
Cc: security at openid.net
Subject: Re: [security] Validating openid.identity in authenticationresponses


On 16-Nov-07, at 9:01 AM, David Recordon wrote:
> This is actually desired functionality to allow for "directed
> identity".  The use case here is that an End User might type their OP
> Identifier such as "http://aol.com" to start the discovery process.
> Then while at the OP, they could potentially create a new OpenID
> Identifier on the fly or might only have one which is where this can
> also serve as a convenience feature.

I'll add to that:
- OP initiated login
- user changing their mind at the OP (OP can keep better track of  
which identifiers the user presented at each RP)


More information about the security mailing list