Yet Another Delegation Thread

[Dick Hardt]

+1

Glad to see that we have settled on one identifier parameter

On 23-Oct-06, at 7:07 PM, Drummond Reed wrote:

> Here's another way to summarize the conclusions David and I reached  
> in our
> analysis today:
>
> 1) In OpenID Authentication 1.1, if there is a difference between the
> identifier the user wants to assert to an RP and the identifier the  
> IdP
> wants to assert for the user (lets just call them ID1 and ID2),  
> then the
> mapping from ID1 to ID2 can only be handled by the RP (using the  
> OpenID
> delegate feature).
>
> 2) Josh and Mart have argued that in OpenID Authentication 2.0 an  
> IdP should
> also be able to handle the mapping between ID1 and ID2, and indeed  
> in the
> directed identity use case, the IdP MUST handle this mapping.
>
> 3) What David and I realized today is that there are even use cases  
> for BOTH
> the RP and IdP doing the mapping. In other words, even if an RP  
> maps from
> ID1 to ID2 and passes ID2 to the IdP, there shouldn't be anything  
> to prevent
> the IdP from mapping ID2 to ID3 and passing ID3 back to the RP (as  
> long as
> the RP verifies the IdP is authoritative for ID3). Example: I log  
> into RP
> using one URI#1, which maps in my XRDS document to another IdP- 
> specific
> URI#2, and then when logging into my IdP it reminds me that I  
> previously
> used URI#3 at this RP, so I choose URI#3.
>
> 4) Therefore, as long as the protocol: a) REQUIRES the RP to do the  
> mapping
> from ID1 to ID2 if present in the HTML or XRDS (which gives the user
> IdP-independent mapping if the user wants it), and b) ALLOWS the  
> IdP to do
> the mapping from whatever identifier it receives (ID1 or ID2) to  
> whatever
> identifier it wants to assert on behalf of the user (ID3), then all  
> use
> cases are supported. A user can take advantage of RP mapping, IdP  
> mapping,
> or both.
>
> 5) This flexibility means that, with the rules David wrote, only one
> identifier parameter should be needed (although, as David suggests,  
> a second
> parameter that is only a display hint from the RP to the IdP might  
> be a help
> -- and I would argue that it could work in the other direction as  
> well, but
> again only as a display hint.)
>
> =Drummond
>
> -----Original Message-----
> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On  
> Behalf
> Of Recordon, David
> Sent: Monday, October 23, 2006 6:09 PM
> To: specs at openid.net
> Subject: Yet Another Delegation Thread
>
> So been going through all of this up in Seattle with Drummond and  
> think
> I fully have my head around this.
>
> Thinking we have the following cases, which Draft 10 basically already
> addresses.  In any of the responses, the IdP MAY return a differing
> value for "openid.identity" than the RP requested.  This obviously has
> varying degrees of usefulness depending on the specific situation.   
> See
> below for "rules" RP must follow to protect itself from bogus
> assertions.
>
> 1) IdP Registered
> 	a) Entered http://user.myidp.com   (IdP implicitly knows it
> owns)
>             <URI> -> http://myidp.com/server.cgi
>
>          Request
>             openid.identity -> http://user.myidp.com
>          Response
>             openid.identity -> http://user.myidp.com
>
> 	b) Entered http://user.example.com (IdP has an out of band
> "registration" process where it verifies via discovery)
>             <URI> -> http://myidp.com/server.cgi
>
>          Request
>             openid.identity -> http://user.example.com
>          Response
>             openid.identity -> http://user.example.com
>
> 2) Delegated (IdP knows nothing about what the user entered)
> 	a) Entered http://user.example.com
>             <URI>             -> http://myidp.com/server.cgi
>             <OpenID:Delegate> -> http://user.myidp.com (IdP  
> Controlled)
>
>          Request
>             openid.identity -> http://user.myidp.com
>          Response
>             openid.identity -> http://user.myidp.com
>
> 	b) Entered =user.example (or @2idi for Directed Identity case)
>             <URI>             -> http://myidp.com/server.cgi
>             <OpenID:Delegate> -> http://user.myidp.com (IdP  
> Controlled)
>
>          Request
>             openid.identity -> iNumber (LocalID ? <LocalID /> :
> <CanonicalID />)
>          Response
>             openid.identity -> iNumber
>
> 3) Directed Identity
>       Entered http://myidp.com (IdP Registered)
>             <URI>  -> http://myidp.com/server.cgi
>             <Type> -> http://openid.net/identifier_select/2.0
>
>       Request
>             openid.identity -> http://openid.net/identifier_select/2.0
>       Response
>             openid.identity -> http://user.myidp.com (IdP Registered,
> though not necessarily on same domain)
>
>
> I would argue, that this actually accomplishes what is needed;  
> providing
> the following rules:
> 1) Before starting a transaction, the RP MUST validate that the IdP is
> authoritative for the URI it is requesting an assertion about through
> the discovery process.
>
> 2a) If the RP ever receives a response value from IdP differing in the
> URI assertion it requested, it MUST validate that the IdP is
> authoritative for that URI via the discovery process.  This is due to
> that the IdP's response value for "openid.identity" does not have  
> to be
> the same as the RP's request value in any of these three cases.
>
> 2b) In the Directed Identity case, the RP MUST always validate that  
> the
> IdP is authoritative for the URI returned in its assertion via the
> discovery process.
>
> So the one time that an additional parameter is useful, is in the
> Delegated Case where it would be useful to the IdP to know what the  
> user
> entered at the RP.  This has certain privacy implications, though most
> of the data is public to begin with in terms of the HTML/XRDS  
> semantics.
> There also is the concern that since the IdP is signing the  
> response, it
> would have to also check that it is authoritative over this other
> parameter.  If this is still a design goal, I'd propose we add
> "openid.display" (or whatever we want to call it) which the RP  
> sends in
> the request solely to aid the IdP when interacting with the user.  The
> IdP would then still make an assertion about the value of
> "openid.identity" and thus not return "openid.display" in the  
> response.
> This thus continues placing the burden on the RP to verify all of the
> assertions made in the protocol.
>
> In the end this remains backwards compatible with 1.x, though also
> broadens the delegation model as Josh and Mart have previously
> described.  This also places no additional burden on the IdP, since in
> every case the RP is responsible for verifying that the IdP is
> authoritative for the assertion made.  While the IdP should not make
> assertions that are not true, at the end of the day the RP should be
> verifying the validity of every assertion in any case to protect  
> itself.
>
> --David
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>