[Openid-specs-ab] userid/domain/server_id

[John Bradley]

An example would be Equifax issuing a JWT with a subject that is an ID issued by Google.

In one of the recent connect proposals the subject was a combination of the local userID and the serverID.
That works until you want a third party to say something about the subject and the servierID changes.

We could have two different identifier formats, but that would be confusing.
I think it is better to have a fully qualified identifier and a separate serverID.

In the simple verification case the RP needs to check that the server part of the subject matches the serverID.

One of the other reasons for separating protocol endpoints from names is scaling.

We are likely to see deployments covering perhaps hundreds of Millions of users.

In those cases having multiple endpoints for the same logical name is a nice feature.

The problem is that the trust model of checking the host name for the SSL connection potentially breaks.
I understand the desire for RP simplicity.   We should think through the issue.

John B.
On 2011-01-07, at 5:07 AM, Nat Sakimura wrote:

> I had a talk with JohnB. this morning. 
> Considering third party claims provider use case, it is handy to have a globally unique user identifier. 
> There are two ways of doing it. 
> 
> 1. Use the complex type identifier. e.g., treat the combination of the user_id and server_id/domain as the user identifier. 
> 2. Pre-combine the two such as user_id at server_id OR urn:server_id/user_id etc. 
> 
> John's preference was option 2. above. 
> 
> Also, we have talked a little bit over the domain transition use cases. 
> From time to time, the domain get switched. e.g., facebook.com to fb.com etc. 
> To be insulated from it, it may be wise to use an abstract server_id instead of the domain. 
> (It certainly is the case for relying parties when PPID is being used.) 
> 
> Should we consider this? OR should we stick with the domain? 
> Note: If we are to use an abstract server_id, verification will probably require signature verification. 
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110107/75784add/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110107/75784add/attachment.p7s>