Re: Re[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Dick Hardt]

On 6-Oct-06, at 11:14 AM, Chris Drake wrote:

>
> An ***IdP*** can *initiate* the OpenID login with the RP using
> openid:Token.
>
> How the User arrived at the RP with this token is not the concern of
> the RP.  (could be javascript, browser plugins, participating IdP
> helper CGIs, or even the RP itself).  The point is - the guts of the
> authentication process remains unchanged and is backwards compatible,
> but all the privacy-invasive components that live at the RP are thus
> made *optional*.
>
> Simple as that.  User only needs to remember and use one ID.  User
> only needs to type it one time each day (or however long they elect to
> "stay logged on" for).  Datamatching and privacy invasion are
> eradicated.  No need to key custom IdP anonymity URLs ever.  Even
> facilitates double-blind anonymous logins (with inclusion of a simple
> RP nonce extension).  Win-win-win.

This is a great idea Chris!

Since the protocol from the RP point of view is it receives a POST  
for the browser, how that gets started does not matter to the RP.

Now all we need is a way for the IdP to know which URL to send the post.

A couple options:

1) the RP includes the "login URL" in request messages to the IdP.  
The IdP saves it for allowing the user to bookmark.

2) the RP has the "login URL" somewhere easily discoverable by the IdP

I would propose that both methods are supported.

-- Dick
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Martin Atkins]

Kevin Turner wrote:
>>From http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken
> (change #3):
>> Impact on XRI-based auth:
>>
>> An XRI is, for this purpose, a URI that can be resolved into a URL at
>> which we can do Yadis discovery. Once Yadis discovery begins, flow
>> continues as in the original proposal, where openid:Token can be any
>> URI.
> 
> It's unclear to me whether you intended this to be a change from the
> current specification or not, but it is.  Yadis discovery on URLs
> resolved from XRIs is considered redundant, as there's nothing about
> Yadis discovery that can't be done while resolving the XRI.  Since Yadis
> uses the XRI resolution response format, you even get to use the same
> code.
> 
> So was it your intention to add an extra layer to discovery here, or
> should the above section be reworded?

Sorry. That was sloppy.

I did not intend there to be any change at all. By "Yadis discovery", I 
only meant to say that the RP would look for the relevant service element.

My intention for this proposal has always been to not change anything at 
all beyond terminology, with the exception that openid:Delegate (which 
now has a new name) is required. I only changed it to required to 
reinforce the fact that it is distinct from the public identifier, and 
thus (hopefully) to make the spec easier to understand by removing a 
special case.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Drummond Reed]

+1 to Kevin's point here -- no second discovery step is needed with an XRI.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Kevin Turner
Sent: Friday, October 06, 2006 1:58 PM
To: specs@openid.net
Subject: Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

>From http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken
(change #3):
> Impact on XRI-based auth:
> 
> An XRI is, for this purpose, a URI that can be resolved into a URL at
> which we can do Yadis discovery. Once Yadis discovery begins, flow
> continues as in the original proposal, where openid:Token can be any
> URI.

It's unclear to me whether you intended this to be a change from the
current specification or not, but it is.  Yadis discovery on URLs
resolved from XRIs is considered redundant, as there's nothing about
Yadis discovery that can't be done while resolving the XRI.  Since Yadis
uses the XRI resolution response format, you even get to use the same
code.

So was it your intention to add an extra layer to discovery here, or
should the above section be reworded?


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Kevin Turner]

>From http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken
(change #3):
> Impact on XRI-based auth:
> 
> An XRI is, for this purpose, a URI that can be resolved into a URL at
> which we can do Yadis discovery. Once Yadis discovery begins, flow
> continues as in the original proposal, where openid:Token can be any
> URI.

It's unclear to me whether you intended this to be a change from the
current specification or not, but it is.  Yadis discovery on URLs
resolved from XRIs is considered redundant, as there's nothing about
Yadis discovery that can't be done while resolving the XRI.  Since Yadis
uses the XRI resolution response format, you even get to use the same
code.

So was it your intention to add an extra layer to discovery here, or
should the above section be reworded?


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Chris Drake]

CHRIS DRAKE'S PROPOSED FLOW

1) User *enters* UPI, but a Discovery Agent intercepts this: UPI does
   *not* get posted to RP
2) Discovery Agent sends UPI to IdP
3) IdP authenticates against UPI
4) IdP selects appropriate RP-specific IPI
5) IdP initiates authentication with RP using IPI


Kind Regards,
Chris Drake,
=1id.com



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Kevin Turner]

On Thu, 2006-10-05 at 18:08 -0700, Marius Scurtescu wrote: 
> The only problem it seems to solve is that of vanity identifiers.  
> Switching IdPs where you had an IdP issued identity for the original  
> IdP does not seem to be possible, you have no control over that  
> original identity so you cannot use it anymore. If you had a vanity  
> identity with the original IdP then switching only means pointing  
> your vanity identity to the new IdP.

This much is true.


> Instead of dealing with vanity identities using the delegate tag why  
> not let the IdP manage your vanity identities?

How does this work?  I want to log in to an RP with my vanity identity,
what do I enter?  How does the RP get from what I enter to my IdP?


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Chris Drake]

Hi Martin,

This is getting very close to what I believe is the main important
thing we need in the spec to facilitate privacy, true SingleSignOn,
and to help avoid confusing users by getting them to key IdP URLs.

The only "tweak" I would like to see is right at the start, and is
implemented using OPTIONAL (at the RP) pure client-side stuff (plain
HTML or JavaScript).  The server-side tweak I'd like to see would be
this:

An ***IdP*** can *initiate* the OpenID login with the RP using
openid:Token.

How the User arrived at the RP with this token is not the concern of
the RP.  (could be javascript, browser plugins, participating IdP
helper CGIs, or even the RP itself).  The point is - the guts of the
authentication process remains unchanged and is backwards compatible,
but all the privacy-invasive components that live at the RP are thus
made *optional*.

Simple as that.  User only needs to remember and use one ID.  User
only needs to type it one time each day (or however long they elect to
"stay logged on" for).  Datamatching and privacy invasion are
eradicated.  No need to key custom IdP anonymity URLs ever.  Even
facilitates double-blind anonymous logins (with inclusion of a simple
RP nonce extension).  Win-win-win.

Kind Regards,
Chris Drake
=1id.com


Saturday, October 7, 2006, 2:49:17 AM, you wrote:

MA> Dick Hardt wrote:
>> I like making all identifiers work the same way. The wording around
>> directed identity is somewhat confusing. Would be clearer if there
>> was a complete description of what happened. ie. complete the  
>> transaction. In Directed Identity, the RP needs to do discovery on
>> the identifier provided to make sure the IdP is authoritative for it.
>> 

MA> Perhaps I've misunderstood how directed identity works, but I figured
MA> the flow would work as follows:

MA> * The RP initiates Yadis discovery on http://anon.myidp.com/

MA> * The IdP returns a document naming its authentication endpoint (in the
MA> "URI" field) and a special anonymous token as openid:Token. openid:Token
MA> may be the same as the public identifier from the previous step, but
MA> this is not required.

MA> * The RP initiates OpenID auth to the named endpoint using the openid:Token.

MA> * The IdP notes that the special "anonymous" token has been used, but it
MA> knows who the remote user is (via Cookies, for example) so it can 
MA> generate an identifier and remember that it belongs to that user/RP combo.

MA> * IdP responds to RP with the generated public identifier (which *is*
MA> publically resolvable, of course.)

MA> * RP resolves the IdP-provided public identifier, where the IdP will
MA> provide for Yadis discovery and specify that it is authoritative for
MA> that URL.

MA> * We're done.

MA> The important thing is that, just as I've separated the public 
MA> identifier from the IdP token (or handle, if you like), this separation
MA> also applies to the IdP-generated public identifier.

MA> (sorry that this is a bit rough. I've not really spent the necessary
MA> amount of time preparing the above and I'm in a hurry, so if there are
MA> spots where I'm not clear I apologise and I'll clarify later! :) )

MA> ___
MA> specs mailing list
MA> specs@openid.net
MA> http://openid.net/mailman/listinfo/specs



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Drummond Reed]

+1. Josh is right. Ultimately there are three identifiers involved in all
interactions between the User, the RP, and the IdP:

1) User-Presented-Identifier (UPI): the identifier entered by the User at
the RP.

2) RP-Persisted-Identifier (RPI): the identifier that will be persisted by
the RP in order to recognize the User when next the User returns.

3) IdP-Persisted-Identifier (IPI): the identifier persisted by the IdP
against which the IdP will authenticate the user.

Here's a simple analysis of how these are used during the different flows:

OPENID 1.X

1) User enters UPI
2) RP discovers IPI (if any -- otherwise UPI = IPI)
3) RP sends IPI to IdP
4) IdP authenticates against IPI
5) IdP responds with IPI

JOSH'S PROPOSED FLOW

1) User enters UPI
2) RP sends UPI to IdP
3) IdP discovers IPI (if any -- otherwise UPI = IPI)
4) IdP authenticates against IPI
5) IdP responds with UPI

OPENID 2.0 DIRECTED IDENTITY FLOW

1) User enters UPI (where UPI = identifier of directed identity server)
2) RP sends special UPI ("http://openid.net/identifier_select/2.0";) to IdP
3) IdP discovers IPI
4) IdP authenticates against IPI
5) IdP responds with RPI

OPENID 2.0 XRI CANONICAL ID FLOW

1) User enters UPI (XRI i-name)
2) RP discovers RPI (XRI i-number = CanonicalID)
3) RP sends RPI to IdP
4) IdP authenticates against RPI (RPI = IPI)
5) IdP responds with RPI

*

On this basis, it seems the solution is for the protocol to clearly
recognize all three identifier types. This would:

a) Support all four flows above.
b) Enable RPs and IdPs to all do the right thing at the right time with the
right identifier
c) Eliminate confusion over which identifier is doing what in each flow.

So we would go from openid.identity, which is currently overloaded, to:

openid.identity = IPI
openid.persist = RPI
openid.display = UPI

Or whatever names everyone can agree on.

=Drummond 


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Josh Hoyt
Sent: Friday, October 06, 2006 10:34 AM
To: Martin Atkins
Cc: specs@openid.net
Subject: Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

On 10/6/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
> * The IdP returns a document naming its authentication endpoint (in the
> "URI" field) and a special anonymous token as openid:Token. openid:Token
> may be the same as the public identifier from the previous step, but
> this is not required.

Anonymous is not a good thing to call this. What IdP-driven identifier
selection does is let the IdP help the user choose an identifier. In
no way is the response any more anonymous than an identifier that was
typed in by the user.

It is true that one of the motivations for this feature is the great
improvement in the user experience for site-specific identifiers, but
the IdP could just as well return a cross-site identifier for the
user.

Sorry to go on about terminology, but I think it's important for
understanding what's really going on.

Josh
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Josh Hoyt]

On 10/6/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
> * The IdP returns a document naming its authentication endpoint (in the
> "URI" field) and a special anonymous token as openid:Token. openid:Token
> may be the same as the public identifier from the previous step, but
> this is not required.

Anonymous is not a good thing to call this. What IdP-driven identifier
selection does is let the IdP help the user choose an identifier. In
no way is the response any more anonymous than an identifier that was
typed in by the user.

It is true that one of the motivations for this feature is the great
improvement in the user experience for site-specific identifiers, but
the IdP could just as well return a cross-site identifier for the
user.

Sorry to go on about terminology, but I think it's important for
understanding what's really going on.

Josh
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Gabe Wachob]

What does Liberty call it?

(Gabe ducks..)

Some humor for a Friday...

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Martin Atkins
> Sent: Friday, October 06, 2006 9:42 AM
> To: specs@openid.net
> Subject: Re: [PROPOSAL] Separate Public Identifier from IdP Identifier
> 
> Dick Hardt wrote:
> >
> > I think "Token" is not a good name, so many other meanings. Perhaps
> > "handle"?
> >
> 
> I agree that "token" is not the best name. "handle" is still not that
> specific, but at least it isn't used in too many other places.
> 
> (We do already have an "assoc_handle", however.)
> 
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Martin Atkins]

Dick Hardt wrote:
> I like making all identifiers work the same way. The wording around  
> directed identity is somewhat confusing. Would be clearer if there  
> was a complete description of what happened. ie. complete the  
> transaction. In Directed Identity, the RP needs to do discovery on  
> the identifier provided to make sure the IdP is authoritative for it.
> 

Perhaps I've misunderstood how directed identity works, but I figured 
the flow would work as follows:

* The RP initiates Yadis discovery on http://anon.myidp.com/

* The IdP returns a document naming its authentication endpoint (in the 
"URI" field) and a special anonymous token as openid:Token. openid:Token 
may be the same as the public identifier from the previous step, but 
this is not required.

* The RP initiates OpenID auth to the named endpoint using the openid:Token.

* The IdP notes that the special "anonymous" token has been used, but it 
knows who the remote user is (via Cookies, for example) so it can 
generate an identifier and remember that it belongs to that user/RP combo.

* IdP responds to RP with the generated public identifier (which *is* 
publically resolvable, of course.)

* RP resolves the IdP-provided public identifier, where the IdP will 
provide for Yadis discovery and specify that it is authoritative for 
that URL.

* We're done.

The important thing is that, just as I've separated the public 
identifier from the IdP token (or handle, if you like), this separation 
also applies to the IdP-generated public identifier.

(sorry that this is a bit rough. I've not really spent the necessary 
amount of time preparing the above and I'm in a hurry, so if there are 
spots where I'm not clear I apologise and I'll clarify later! :) )

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Martin Atkins]

Dick Hardt wrote:
> 
> I think "Token" is not a good name, so many other meanings. Perhaps  
> "handle"?
> 

I agree that "token" is not the best name. "handle" is still not that 
specific, but at least it isn't used in too many other places.

(We do already have an "assoc_handle", however.)

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Joaquin Miller]

... the full
proposal on the OpenID wiki:

<
http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken
>
I like this.  The so-called "normal" case is an
optimization.  Optimizations done for the convenience of computers
should be hidden from users.
Cordially, Joaquin


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Dick Hardt]

I like making all identifiers work the same way. The wording around  
directed identity is somewhat confusing. Would be clearer if there  
was a complete description of what happened. ie. complete the  
transaction. In Directed Identity, the RP needs to do discovery on  
the identifier provided to make sure the IdP is authoritative for it.

I think "Token" is not a good name, so many other meanings. Perhaps  
"handle"?

-- Dick

On 4-Oct-06, at 11:34 AM, Martin Atkins wrote:

>
> Currently the conceptual model is that each user has a "public" (that
> is, presented to RPs) identifier, but can optionally create additional
> identifiers which "delegate" to the real identifier. The delegate
> functionality has several purposes, including:
>   * "Vanity" identifiers on personal domains while letting someone  
> else
> do the hard work in running the IdP.
>   * Ability to switch IdPs without losing identity
>
> However, experience has shown that the above model is often  
> difficult to
> grasp for those new to OpenID. This proposal is really just a set of
> terminology changes and an alternative conceptual model that aim to  
> make
> the delegate functionality easier to understand. It does not change  
> the
> mechanism of delegation at all, though it does change the discovery
> protocol.
>
> I've placed the full proposal on the OpenID wiki:
>  
>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Marius Scurtescu]

On 5-Oct-06, at 3:36 PM, Recordon, David wrote:

> Conceptually I think I like this model.  It does seem easier to
> understand.
>
> Other thoughts on this?

I am still not sure how the delegated identifier is useful. I did  
miss the earlier discussions, so probably I don't have enough  
background on this.

The only problem it seems to solve is that of vanity identifiers.  
Switching IdPs where you had an IdP issued identity for the original  
IdP does not seem to be possible, you have no control over that  
original identity so you cannot use it anymore. If you had a vanity  
identity with the original IdP then switching only means pointing  
your vanity identity to the new IdP. So it really boils down to  
controlling your vanity identity.

Instead of dealing with vanity identities using the delegate tag why  
not let the IdP manage your vanity identities? When you register with  
an IdP you should be able to register additional vanity identities,  
as many as you want. You have to prove to the IdP that you control  
them, but this is a different problem (I'll get back to this).

This is similar to domain names (identities) and hosting companies  
(IdPs). You can configure your domain to point to a different hosting  
company (this is like editing your Yadis document to point to another  
IdP). If you don't care about your own domain then you can get cheap  
or free hosting but at some URL controlled by the hosting company  
(these would be the IdP issued identities).

Most of the sites you deal with are RPs, not IdPs. Also, you would  
trust more your IdP then any RP. The link between multiple vanity  
identifiers will be know only to the IdP, the RPs will not know this.

Now, how would the IdP check that you indeed control a vanity  
identity? First of all, you have to point to that IdP. Second, the  
IdP will check that no one else claimed this vanity identity. So  
unless there is an attempt by someone else to claim the same identity  
the IdP can take your word for it. If it wants to go one step further  
(or if there is a conflict) then the IdP can ask you for more proof  
that you own this identity:
- it can send a verification email associated with the domain of this  
identity (if it is a root domain)
- it can ask you to place a special file under this domain/path
- it can ask you to add special headers in the HTML page of this  
identity
- it can ask you to add a special field into the yadis document (and  
this field could be a replacement for the delegate element)

Does this make sense? What am I missing?

Thanks,
Marius


>
> --David
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Martin Atkins
> Sent: Wednesday, October 04, 2006 11:34 AM
> To: specs@openid.net
> Subject: [PROPOSAL] Separate Public Identifier from IdP Identifier
>
>
> Currently the conceptual model is that each user has a "public" (that
> is, presented to RPs) identifier, but can optionally create additional
> identifiers which "delegate" to the real identifier. The delegate
> functionality has several purposes, including:
>   * "Vanity" identifiers on personal domains while letting someone  
> else
> do the hard work in running the IdP.
>   * Ability to switch IdPs without losing identity
>
> However, experience has shown that the above model is often  
> difficult to
> grasp for those new to OpenID. This proposal is really just a set of
> terminology changes and an alternative conceptual model that aim to  
> make
> the delegate functionality easier to understand. It does not change  
> the
> mechanism of delegation at all, though it does change the discovery
> protocol.
>
> I've placed the full proposal on the OpenID wiki:
>  <http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken>
>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Recordon, David]

Conceptually I think I like this model.  It does seem easier to
understand.

Other thoughts on this?

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Wednesday, October 04, 2006 11:34 AM
To: specs@openid.net
Subject: [PROPOSAL] Separate Public Identifier from IdP Identifier


Currently the conceptual model is that each user has a "public" (that
is, presented to RPs) identifier, but can optionally create additional
identifiers which "delegate" to the real identifier. The delegate
functionality has several purposes, including:
  * "Vanity" identifiers on personal domains while letting someone else
do the hard work in running the IdP.
  * Ability to switch IdPs without losing identity

However, experience has shown that the above model is often difficult to
grasp for those new to OpenID. This proposal is really just a set of
terminology changes and an alternative conceptual model that aim to make
the delegate functionality easier to understand. It does not change the
mechanism of delegation at all, though it does change the discovery
protocol.

I've placed the full proposal on the OpenID wiki:
 <http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken>


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

[PROPOSAL] Separate Public Identifier from IdP Identifier

[Martin Atkins]

Currently the conceptual model is that each user has a "public" (that 
is, presented to RPs) identifier, but can optionally create additional 
identifiers which "delegate" to the real identifier. The delegate 
functionality has several purposes, including:
  * "Vanity" identifiers on personal domains while letting someone else 
do the hard work in running the IdP.
  * Ability to switch IdPs without losing identity

However, experience has shown that the above model is often difficult to 
grasp for those new to OpenID. This proposal is really just a set of 
terminology changes and an alternative conceptual model that aim to make 
the delegate functionality easier to understand. It does not change the 
mechanism of delegation at all, though it does change the discovery 
protocol.

I've placed the full proposal on the OpenID wiki:
 


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs