Hello List
I have written up what I think are the requirements for identifiers
so that we can see if we agree to those. If so, then the proposal
revision I have below may be an acceptable solution that keeps things
simple and provides backwards compatibility.
Sorry that we are still having this discussion, but it is important
if we are going to make a change, that we get it right.
-- Dick
Basic Protocol:
---------------------
A) User provides the RP with an identifier of some kind
B) The RP uses that identifier to find the user's IdP (the RP may
discover other useful information in the process
C) the RP sends a request to the IdP. This request is not signed and
could be modified between the RP and the IdP
D) The IdP decodes the request and interacts with the user
E) The IdP sends a response to the RP that includes an the identifier
the user would like to be known as
F) The RP verifies the response is valid and from the IdP
G) The RP verifies the IdP is authoritative for the identifier
provided (there is some funkiness with delegation)
Requirements:
---------------------
1) 1.x compatability
We want existing 1.x OpenID IdPs and RPs to work unmodified
2) portable identifiers
This is a separation of the identifier from the identity provider.
The document returned by resolving the identifier is under the
control of the user and contains the IdP(s) authoritative for the
identifier. This was a feature in OpenID 1.x that was accomplished
with a delegation statement. The IdP was not aware of the portable
identifier which may have some privacy advantages. In current
implementations the delegate tag is publicly visible, so the IdP can
easily search to find the delegates. An existing privacy advantage is
that if a user has multiple delegates pointing to the same delegate,
the IdP does not know which one a given RP is using. Not sure how
valuable that is. Current thinking is that it is useful for the IdP
to be aware of the delegate and to manage the portable identifiers.
See Delegate Identifier Binding below for the implications of this
change.
3) XRI support
This is a new feature in 2.0 that allows the user to provide an i-
name rather then a URL to the RP.
4) directed identity
By allowing the user to provide the IdP URL to the RP rather then
their OpenID, the IdP can manage a unique URL for each RP, or even
generate a new one each time the user visits the RP. RPs cannot use
the URL to collude about the user.
5) IdP identifier management
By providing the RP the IdP URL, the IdP can now help the user decide
which identifier to present to the RP. The IdP could even assist the
user if the user provided an OpenID URL or i-name. For example, the
IdP can remember what identifier(s) the user presented in the past so
that the user does not have to remember which identifier/persona they
used at which site and can quickly correct mistakes.
6) Simplicity
It is desirable to keep things simple and easy to understand and
implement.
7) Secure
It is desirable that OpenID 2.0 does not introduce new security
concerns. We accept DNS spoofing as being an acceptable risk.
Delegate Identifier Binding:
--------------------------------------
For consistency with previous discussions, let's call the identifier
contained in the delegate the IdP-specific identifier. In OpenID 1.x
the RP bound the IdP-specific identifier to the public identifier.
The IdP was not explicitly aware of the public identifier. It is
desirable in OpenID 2.0 to allow the IdP to have explicit knowledge
of the public identifier. This allows the IdP to allow the user
select the public identifier if the IdP URL was given to the RP.
There also now are three choices on what the response to the RP can
contain:
1) the IdP-specific identifier as was done in OpenID 1.x which leaves
binding of the IdP-specific identifier and public identifier to the RP
2) the public identifier which implies the binding of the IdP-
specific identifier and the public identifier is done by the IdP. In
this case, the RP does not need to understand how the IdP is binding
the public identifier and the IdP-specific identifier, and the IdP-
specific identifier does not need to be resolvable
3) both the IdP-specific identifier and the public identifier. In
this case the RP is binding the public identifier to both the IdP-
specific identifier and the IdP
Current Proposal:
------------------------
The current proposal:
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
http://openid.net/pipermail/specs/2006-October/000650.html
proposes binding using option (3). Issues with this are:
a) The IdP is able to do the binding, and the binding mechanism can
be independent of the RP.
b) Both IdP and RP are doing the same work. Inefficient, and more
points of security failure.
c) the message and flow is different from when non-portable
identifiers are returned
Revised Proposal:
-------------------------
* preserve openid.identity to have the same functionality as it does
in OpenID 1.x
* Add a new parameter, openid.identifier to reflect the new
functionality in OpenID 2.0 (perhaps not the best name, suggestions?)
* use LocalID element for the IdP specific identifier, the delegate
statement would only be for OpenID 1.x
* only one of openid.identity OR openid.identifier are in a message
A) If the RP or IdP are OpenID 1.x, then openid.identity is used and
things work how they did in OpenID 1.x
the value of openid.identity in the request MUST match the
openid.identity in the response. (this was previously not specified,
and likely is how existing code expects things to work)
This meets requirement (1)
B) If the RP and the IdP are both OpenID 2.0, then openid.identifier
SHOULD be used.
if the identifier is an XRI or IdP URL, then openid.identifier MUST
be used.
if the user provided an OpenID URL, openid.identifier is the URL
if the user provided an IdP URL, openid.identifier is http://
openid.net/identifier_select/2.0
If the user provided an i-name, openid.identifier is the i-number
In the response, openid.identifier may be an i-number or an OpenID
URL. The response identifier does not need to match the request
identifier.
This meets requirement (5)
If we can get consensus on this, I will get a patch to the latest
spec to reflect.
-- Dick
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
