Yet Another Delegation Thread

Drummond Reed drummond.reed at cordance.net
Tue Oct 24 02:07:26 UTC 2006


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




More information about the specs mailing list