[Openid-specs-ab] Identifiers and discovery.
Breno de Medeiros
breno at google.com
Fri Apr 15 16:42:32 UTC 2011
On Wed, Apr 13, 2011 at 18:13, Mike Jones <Michael.Jones at microsoft.com> wrote:
> What would you like to see the algorithm be to extract an IdP from a Principal string if we don't use discovery for that?
E.g.: "iss" = "https://accounts.example.com/"
We could use the /.well-known path. There are several choices. One is
that the idp auth endpoint is completely specified by the spec.
1. "https://accounts.example.com/.well-known/openid/idp/auth" and
similarly for all endpoints
2. Another is that the spec identifiers how to discover all endpoints,
including the 'auth' endpoint. Upon fetching this endpoint:
"https://accounts.example.com/.well-known/openid/disco/endpoints"
One would get some JSON or JWT token asserting the data:
{
'auth' : 'https://accounts.example.com/openid/auth',
'get_id_token' : 'https://accounts.example.com/openid/get_id_token',
....
}
3. The version of 2 using SWT-discovery-like semantics would be to
fetch instead:
https://accounts.example.com/.well-known/openid/disco/endpoints?endpoint=auth
Which would return
"https://accounts.example.com/.well-known/openid/auth' in this
instance
In other words, it is possible to derive the endpoint in a standard
form or via discovery. I don't think anyone in this forum has objected
to using discovery to find endpoints given an issuer. I just prefer
that we don't define discovery on identifiers and mandate special
format for them.
I also believe that discovery of endpoints and services that involve
the user_id (to return information customized for the user) should
likely be an OAuth2-protected resource (which might return something
useful even if you don't have a token) so that we can unify protected
and public discovery.
>
> -- Mike
>
> -----Original Message-----
> From: Chuck Mortimore [mailto:cmortimore at salesforce.com]
> Sent: Wednesday, April 13, 2011 6:11 PM
> To: Mike Jones
> Cc: Breno de Medeiros; John Bradley; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>
>
> On Apr 13, 2011, at 6:01 PM, "Mike Jones" <Michael.Jones at microsoft.com> wrote:
>
>> Yes, that case is easy. But it makes other cases, where we *do* want to discover services for the principal harder, and inconsistent with the OpenID case. Better to use the same identifier string for all cases and have a simple rule for extracting the IdP substring from the Principal string than to use one identifier in some cases and another identifier for the same thing in other cases.
>>
>> The rule I was thinking of is dirt-simple: The IdP string is everything up to the last "/" in the Principal URL. It doesn't get much simpler than that.
>
> For what it's worth, that algo would break my current deployment. I use tenant_id/user_id as the user identifier portion of my principal URL.
>
> -cmort
>
>
>>
>> (Yes, the other possible dirt-simple rule is that the IdP is just the
>> host component of the Principal URL. Discussion on which rule is
>> better is welcome.)
>>
>> -- Mike
>>
>> -----Original Message-----
>> From: Breno de Medeiros [mailto:breno at google.com]
>> Sent: Wednesday, April 13, 2011 5:54 PM
>> To: John Bradley
>> Cc: Mike Jones; openid-specs-ab at lists.openid.net
>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>>
>> On Wed, Apr 13, 2011 at 17:24, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>> I think Mike is proposing that their be some sort of domain pattern match check rather than discovery.
>>>
>>> He wants to be able to do discovery on the identifier, not require it.
>>>
>>> You might say have some rule to concatenate the user info endpoint and user id to pass that to the SWD service.
>>>
>>> The other option is to have the IdP construct the string and do a regex on the start..
>>
>> I prefer to have a mechanism that queries the IDP on a well-known location. Not construction, no regex matching. Easy.
>>
>>>
>>> John B.
>>> On 2011-04-13, at 8:19 PM, Breno de Medeiros wrote:
>>>
>>>> On Wed, Apr 13, 2011 at 17:15, Mike Jones <Michael.Jones at microsoft.com> wrote:
>>>>> Can you give an example of what you mean by "tying discovery to authentication"? There's obviously something specific you have in mind here but I'll admit that I don't know what it is. (I suspect that may be true of others as well.) Having us all understand that might help clarify things.
>>>>
>>>> How do we know that the IDP is authoritative for the user_id when
>>>> the user_id is in a global namespace? By doing discovery. Without
>>>> that step we can't authenticate.
>>>>
>>>> If the user_id is scoped in the issuer namespace, then no additional
>>>> validation is required. The RP already has issuer-scoped identifiers
>>>> and won't create username collisions.
>>>>
>>>>>
>>>>> I obviously agree that discovery should only be involved when it provides value.
>>>>>
>>>>> Going back to my favorite example, being able to discover the location of a user's calendar service clearly adds value. We need that to be possible, even though it's not part of OpenID.
>>>>>
>>>>> -- Mike
>>>>>
>>>>> -----Original Message-----
>>>>> From: Breno de Medeiros [mailto:breno at google.com]
>>>>> Sent: Wednesday, April 13, 2011 5:11 PM
>>>>> To: Mike Jones
>>>>> Cc: John Bradley; openid-specs-ab at lists.openid.net
>>>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>>>>>
>>>>> On Wed, Apr 13, 2011 at 17:08, Mike Jones <Michael.Jones at microsoft.com> wrote:
>>>>>> Complexity is the enemy of adoption. Turning discovery into a full OAuth protected resource is overkill. We want to developers to say "of course I can build that"!
>>>>>
>>>>> Tying discovery with authentication will prevent adoption by making the most basic function complex.
>>>>>
>>>>> Discovery should be involved when it adds value.
>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Breno de Medeiros [mailto:breno at google.com]
>>>>>> Sent: Wednesday, April 13, 2011 5:06 PM
>>>>>> To: John Bradley
>>>>>> Cc: Mike Jones; openid-specs-ab at lists.openid.net
>>>>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>>>>>>
>>>>>> On Wed, Apr 13, 2011 at 17:04, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>>>>>> As a counter argument.
>>>>>>>
>>>>>>> By not having the non-reassignable ID discoverable the RP must now also store a additional identifier for the user if it wants to do public discovery of that user again for some reason.
>>>>>>>
>>>>>>> I think the better answer is to have a oAuth protected discovery service that the RP can access like any other for the user.
>>>>>>
>>>>>> That also has the advantage of unifying public and protected discovery.
>>>>>>
>>>>>>>
>>>>>>> John B.
>>>>>>> On 2011-04-13, at 7:56 PM, Breno de Medeiros wrote:
>>>>>>>
>>>>>>>> Yes, audience needs to be global in scope.
>>>>>>>>
>>>>>>>> user_ids need not, and they can't safely be declared global
>>>>>>>> without tying in discovery with authentication, which I'd rather
>>>>>>>> not do. I strongly prefer that discovery be defined to solve the
>>>>>>>> problems for which it is required to be present, e.g., for a
>>>>>>>> generic claims architecture, where the context makes obvious why
>>>>>>>> discovery is required.
>>>>>>>>
>>>>>>>> On Wed, Apr 13, 2011 at 16:50, Mike Jones <Michael.Jones at microsoft.com> wrote:
>>>>>>>>> The Audience values also need to also be global in scope. Correct?
>>>>>>>>>
>>>>>>>>> As an example why this needs to be true, if the audience were simply the user-id string "mbj", then something intended for mbj at microsoft.com might be received/intercepted an considered valid if used by mbj at gmail.com.
>>>>>>>>>
>>>>>>>>> -- Mike
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Breno de Medeiros [mailto:breno at google.com]
>>>>>>>>> Sent: Wednesday, April 13, 2011 4:47 PM
>>>>>>>>> To: Mike Jones
>>>>>>>>> Cc: Chuck Mortimore; Axel.Nennker at telekom.de;
>>>>>>>>> openid-specs-ab at lists.openid.net
>>>>>>>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>>>>>>>>>
>>>>>>>>> You can have a global federation with IDP-scoped user identifiers, as long as the IDP/issuer names are global in scope.
>>>>>>>>>
>>>>>>>>> On Wed, Apr 13, 2011 at 16:40, Mike Jones <Michael.Jones at microsoft.com> wrote:
>>>>>>>>>> I agree that uniqueness is only required within the federation.
>>>>>>>>>> But if you adopt the OpenID Foundation's position that we are
>>>>>>>>>> trying to build open systems where any party can be a full
>>>>>>>>>> participant, then one of the things that our architecture needs to support is precisely a global federation.
>>>>>>>>>> (And yes, of course, being a full participant in any
>>>>>>>>>> particular context requires that the party is appropriately
>>>>>>>>>> trusted by the other parties with which it is interacting.)
>>>>>>>>>> But before trust can be established, the first step is being
>>>>>>>>>> able to identify and perform discovery on the participants in
>>>>>>>>>> the global federation to discover their services that you need to interact with.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I obviously agree with you that any TRUST decision based on a
>>>>>>>>>> claim must be based upon the issuer of that claim. But that's
>>>>>>>>>> actually independent of whether the IDENTIFIER for a principal
>>>>>>>>>> (which yes, would be used in a claim signed by an issuer) is globally unique or not.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Mike
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> From: Chuck Mortimore [mailto:cmortimore at salesforce.com]
>>>>>>>>>> Sent: Wednesday, April 13, 2011 4:31 PM
>>>>>>>>>>
>>>>>>>>>> To: Mike Jones; Axel.Nennker at telekom.de; breno at google.com
>>>>>>>>>> Cc: openid-specs-ab at lists.openid.net
>>>>>>>>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/13/11 4:10 PM, "Mike Jones" <Michael.Jones at microsoft.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Taking your viewpoint for a minute, yes, in SWD the principal
>>>>>>>>>> will of course be interpreted by the site at which discovery
>>>>>>>>>> is being performed. This somewhat corresponds to it being relative to an issuer, I suppose.
>>>>>>>>>>
>>>>>>>>>> It really must be interpreted in the context of the issuer,
>>>>>>>>>> else you'd have issuers asserting principals for which they are not authoritative.
>>>>>>>>>>
>>>>>>>>>> As a thought experiment, are you also proposing that an
>>>>>>>>>> audience value could/should also be similarly scoped in some manner?
>>>>>>>>>>
>>>>>>>>>> In federation deployments, the issuer and audience must be
>>>>>>>>>> unique within the federation. It's not mandatory that they
>>>>>>>>>> are globally unique. We could go for a global federation here
>>>>>>>>>> which would change that, but I suspect that would actually limit some use-cases.
>>>>>>>>>>
>>>>>>>>>> And do you agree with my architectural statement that the same
>>>>>>>>>> entity could be any of a principal, an issuer, or an audience
>>>>>>>>>> restriction value? If so, the your statement that an issuer
>>>>>>>>>> should be unique also implies that so should a principal and
>>>>>>>>>> an audience restriction value, as they are logically of the same kind.
>>>>>>>>>>
>>>>>>>>>> I agree that an entity may be playing multiple roles, however
>>>>>>>>>> we always need to interpret a claim in the context of who is making it.
>>>>>>>>>>
>>>>>>>>>> For example, at Salesforce I can act as both a SAML SP and a SAML IDP.
>>>>>>>>>> If a customer passes me an assertion I create session for the
>>>>>>>>>> subject relative to the issuer, and check to see if the
>>>>>>>>>> audience is me. If I turn around and act as an IDP, the
>>>>>>>>>> entity id I previously used for audience now becomes my issuer, and I may send the exact same subject.
>>>>>>>>>> However, the receiving service provider needs to interpret
>>>>>>>>>> that subject as relative to me, and not the original IDP, as I'm the
>>>>>>>>>> one making the assertion. It would technically be possible
>>>>>>>>>> to form multi-party claims, or to pass along claims, but in
>>>>>>>>>> all cases you must consider the subject in the light of who's making the assertion.
>>>>>>>>>>
>>>>>>>>>> Note this isn't yet arguing for or against separating them :-)
>>>>>>>>>>
>>>>>>>>>> -cmort
>>>>>>>>>>
>>>>>>>>>> Thanks for the thoughtful discussion.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Mike
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> From: Chuck Mortimore [mailto:cmortimore at salesforce.com]
>>>>>>>>>> Sent: Wednesday, April 13, 2011 4:03 PM
>>>>>>>>>> To: Mike Jones; Axel.Nennker at telekom.de; breno at google.com
>>>>>>>>>> Cc: openid-specs-ab at lists.openid.net
>>>>>>>>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>>>>>>>>>>
>>>>>>>>>> When I said JWT I guess I actually meant JWT bearer token.
>>>>>>>>>> You are correct that JWT on it's own doesn't contain a principal.
>>>>>>>>>>
>>>>>>>>>> I agree that Issuer should be unique and is in JWT, SAML, etc.
>>>>>>>>>> In practice, it's pretty difficult to enforce global
>>>>>>>>>> uniqueness of this without some sort of discovery.
>>>>>>>>>>
>>>>>>>>>> I do not believe that the text of your JWT Bearer Token profile makes "prn"
>>>>>>>>>> globally unique, nor do I think that it should. The
>>>>>>>>>> identifier should always be scoped to the issuer. The result
>>>>>>>>>> may be globally unique, but prn should always be interpreted in context of who's asserting it.
>>>>>>>>>>
>>>>>>>>>> -cmort
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/13/11 3:04 PM, "Mike Jones" <Michael.Jones at microsoft.com> wrote:
>>>>>>>>>> No, I don't believe that captures it accurately, as JWT
>>>>>>>>>> <http://self-issued.info/docs/draft-jones-json-web-token.html>
>>>>>>>>>> does not follow the first model as you wrote below. Both SWD
>>>>>>>>>> <http://self-issued.info/docs/draft-jones-simple-web-discovery.
>>>>>>>>>> htm
>>>>>>>>>> l
>>>>>>>>>>>
>>>>>>>>>> and the OAuth JWT Profile
>>>>>>>>>> <http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.htm
>>>>>>>>>> l
>>>>>>>>>>> assume that the principal is a globally unique identifier.
>>>>>>>>>> Likewise, all three of JWT
>>>>>>>>>> <http://self-issued.info/docs/draft-jones-json-web-token.html>
>>>>>>>>>> , SWD
>>>>>>>>>> <http://self-issued.info/docs/draft-jones-simple-web-discovery.
>>>>>>>>>> htm
>>>>>>>>>> l
>>>>>>>>>>> , and the OAuth JWT Profile <http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html> assume that issuer is also a globally unique identifier.
>>>>>>>>>>
>>>>>>>>>> Furthermore, architecturally, a principal in one context may
>>>>>>>>>> be an issuer in another context and an audience restriction
>>>>>>>>>> value in a third. All need to use the same data
>>>>>>>>>> representation for the system to architecturally hang together.
>>>>>>>>>>
>>>>>>>>>> I believe that this is a strong architectural argument why
>>>>>>>>>> https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1
>>>>>>>>>> u
>>>>>>>>>> is the best choice.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Mike
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> From: openid-specs-ab-bounces at lists.openid.net
>>>>>>>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of
>>>>>>>>>> Chuck Mortimore
>>>>>>>>>> Sent: Wednesday, April 13, 2011 2:43 PM
>>>>>>>>>> To: Axel.Nennker at telekom.de; breno at google.com
>>>>>>>>>> Cc: openid-specs-ab at lists.openid.net
>>>>>>>>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>>>>>>>>>>
>>>>>>>>>> I'd be concerned treating either 2 or 3 as an Identitfier.
>>>>>>>>>>
>>>>>>>>>> As I understand it, the main debate is around the persistent
>>>>>>>>>> identifier, and if the issuer and principal are separate
>>>>>>>>>> entities or if the issuer is reflected in the principal. For
>>>>>>>>>> example do we want
>>>>>>>>>> issuer: https://login.salesforce.com/id
>>>>>>>>>> principal: 00DD0000000FH8l/005D0000001Az1u
>>>>>>>>>>
>>>>>>>>>> Or
>>>>>>>>>> principal:
>>>>>>>>>> https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1
>>>>>>>>>> u
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The current ConnectCore uses the first model ( calling them
>>>>>>>>>> user_id and domain ). JWT and SAML follow the first model. I
>>>>>>>>>> believe this is Breno's preference as well.
>>>>>>>>>>
>>>>>>>>>> We've currently deployed the second model; our focus was on
>>>>>>>>>> simplicity and discoverability of the data behind the service.
>>>>>>>>>> It acts are both our user_info endpoint as well as a discovery
>>>>>>>>>> service for endpoints authorized for the access_token.
>>>>>>>>>>
>>>>>>>>>> Does this capture it accurately? Is so, let's just hash out
>>>>>>>>>> the pros/cons of each approach. I'm loathe to starting
>>>>>>>>>> issuing 3 different types of identifiers.
>>>>>>>>>>
>>>>>>>>>> -cmort
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/13/11 1:53 AM, "Axel.Nennker at telekom.de"
>>>>>>>>>> <Axel.Nennker at telekom.de>
>>>>>>>>>> wrote:
>>>>>>>>>> You say:
>>>>>>>>>> 1) Persistent Identifier (in the scope of the OP), never
>>>>>>>>>> reassigned lasjkflasdflsajfljal02384ß20183lskadjfölsafj
>>>>>>>>>>
>>>>>>>>>> 2) UI Identifier
>>>>>>>>>> Fullname: Axel Nennker
>>>>>>>>>> Profilepicref:
>>>>>>>>>> https://www.google.com/s2/photos/public/AIbEiAIAAABECOzLpfXm2d
>>>>>>>>>> n
>>>>>>>>>> 7pA
>>>>>>>>>> E
>>>>>>>>>> iC3
>>>>>>>>>> ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThl
>>>>>>>>>> Z
>>>>>>>>>> jQ3
>>>>>>>>>> M
>>>>>>>>>> mMx
>>>>>>>>>> MAH08_TJz4ElY-WIBPBE1pmNuOStyQ (is this persistent?)
>>>>>>>>>>
>>>>>>>>>> 3) Contact Identifier
>>>>>>>>>> Work: axel.nennker at telekom.de
>>>>>>>>>> Private: ignisvulpis at gmail.com
>>>>>>>>>> Personal: axel at nennker.de
>>>>>>>>>> Tel: +491702275312
>>>>>>>>>>
>>>>>>>>>> Right?
>>>>>>>>>>
>>>>>>>>>> Is https://www.google.com/profiles/ignisvulpis in category 1?
>>>>>>>>>> Never reassigned?
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Breno de Medeiros [mailto:breno at google.com]
>>>>>>>>>>> Sent: Wednesday, April 13, 2011 10:38 AM
>>>>>>>>>>> To: Nennker, Axel
>>>>>>>>>>> Cc: openid-specs-ab at lists.openid.net
>>>>>>>>>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Apr 13, 2011 at 01:15, <Axel.Nennker at telekom.de> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Similar for me. I gave up on trying to attend because 4pm
>>>>>>>>>>> PT is 1am here, so I went to sleep at 23:30 and could have
>>>>>>>>>>> made it for midnight.
>>>>>>>>>>>> Anyway.
>>>>>>>>>>>>
>>>>>>>>>>>> Regarding identifiers: Some people expect that the openid
>>>>>>>>>>> is "fancy" and easy to distiguish.
>>>>>>>>>>>> Example: @t is much cooler than @AxelNennker or pt at fb.com
>>>>>>>>>>> is cooler than user4711 at facebook.com or
>>>>>>>>>>>> https://me.google.com/AxelNennker is cooler than
>>>>>>>>>>> https://me.google.com/users/lasjkflasdflsajfljal02384ß20183ls
>>>>>>>>>>> k
>>>>>>>>>>> adjfölsafj
>>>>>>>>>>>>
>>>>>>>>>>>> The uglier ones achieve the goal of beeing not reassigned
>>>>>>>>>>> much easier than the prettier ones.
>>>>>>>>>>>>
>>>>>>>>>>>> Display Names are an related issue: I guess that there are
>>>>>>>>>>> more than one "Mike Jones" in Microsoft possibly even more
>>>>>>>>>>> than one "Michael B. Jones". Each has a unique identifier
>>>>>>>>>>> which might be reassigned (after a grace period) to a new Michael B. Jones.
>>>>>>>>>>>>
>>>>>>>>>>>> This is not only a technical problem. People want the
>>>>>>>>>>> pretty identifiers.
>>>>>>>>>>>
>>>>>>>>>>> It is a technical problem. If we label the identifiers in the
>>>>>>>>>>> protocol as:
>>>>>>>>>>>
>>>>>>>>>>> - Identifier 1: This is persistent. Use as index in your DB. E.g:
>>>>>>>>>>> a numeric value.
>>>>>>>>>>> - Identifier 2: This is what the user wants you to represent him as.
>>>>>>>>>>> E.g: a name, photo, business card, etc.
>>>>>>>>>>> - Identifier 3: This is what the user thinks you can use to
>>>>>>>>>>> find who he is. E.g.: an email address
>>>>>>>>>>>
>>>>>>>>>>>> The best we can achieve, I think, is that users never see
>>>>>>>>>>> the unique, never reassigned (, maybe global) identifiers.
>>>>>>>>>>>> And that the UI for the display names is powerfull enough
>>>>>>>>>>> to help me to find the Mike Jones I want to reach.
>>>>>>>>>>>>
>>>>>>>>>>>> Example: Consider a blog post with comments by openid
>>>>>>>>>>> users. The blog received a sreg fullname and the
>>>>>>>>>>> openid.claimed_id and openid.identity.
>>>>>>>>>>>> Now it renders the fullname on the html page giving us
>>>>>>>>>>> comment by several Mike Jones. The "social" rendering would
>>>>>>>>>>> allow my user agent to render the comments from my friend
>>>>>>>>>>> list other than comments from people I don't know.
>>>>>>>>>>>>
>>>>>>>>>>>> Ok, this moves away from pure protocol issues and issuer
>>>>>>>>>>> policy to OC best practices and UI issues.
>>>>>>>>>>>> I am not sure how the openid abc wg "protocol" group can
>>>>>>>>>>> solve this non technical problems.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No, that's the mistake OpenID2 fell into. We should have
>>>>>>>>>>> different identifiers for different purposes so that it's
>>>>>>>>>>> foolproof how to deal with this.
>>>>>>>>>>>
>>>>>>>>>>> My proposal is that the identifier used in auth is number 1.
>>>>>>>>>>> You know you can't use to do anything presentational with it.
>>>>>>>>>>> Identifier #2 is the easiest: we return attributes at the
>>>>>>>>>>> user info endpoint that can be used to personalize the user experience.
>>>>>>>>>>> Identifier #3 is missing from the current drafts. I can see
>>>>>>>>>>> two sensible approaches:
>>>>>>>>>>>
>>>>>>>>>>> - Define a discovery protocol that starts by going to the
>>>>>>>>>>> issuer and asking what it knows about the asserted user_id.
>>>>>>>>>>> The advantage of doing this is that we can support both
>>>>>>>>>>> public and protected (meaning that user needs to consent) discovery with the same set of techniques.
>>>>>>>>>>>
>>>>>>>>>>> - Use the email or profile URL (both which will be returned
>>>>>>>>>>> as user
>>>>>>>>>>> attributes) as discovery starting points. This has some
>>>>>>>>>>> advantages in that we may be able to re-use some existing ideas and techniques.
>>>>>>>>>>>
>>>>>>>>>>> Again, what we don't want is an identifier that does all
>>>>>>>>>>> three jobs poorly.
>>>>>>>>>>>
>>>>>>>>>>>> -Axel
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: openid-specs-ab-bounces at lists.openid.net
>>>>>>>>>>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf
>>>>>>>>>>>>> Of Breno de Medeiros
>>>>>>>>>>>>> Sent: Tuesday, April 12, 2011 6:18 PM
>>>>>>>>>>>>> To: openid-specs-ab at lists.openid.net
>>>>>>>>>>>>> Subject: [Openid-specs-ab] Identifiers and discovery.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I hope Nat's well.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I was in a meeting at 3:00pm (that I scheduled after
>>>>>>>>>>> JBradley asserted
>>>>>>>>>>>>> the conference call would take place as usual at 4pm).
>>>>>>>>>>> When I joined,
>>>>>>>>>>>>> Mike Jones and Nat were dropping off the call.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That left JBradley and I on the call. We had a discussion
>>>>>>>>>>>>> on identifiers and discovery.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would like to continue this conversation via email, as
>>>>>>>>>>>>> it's an important one.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Currently, Google's proposal on identifiers is:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Identifiers are unique to the user and non-reassignable
>>>>>>>>>>> within the
>>>>>>>>>>>>> scope of the issuer. However, they need not be globally unique.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Id_tokens attest to the issuer and therefore provide a
>>>>>>>>>>> statement of
>>>>>>>>>>>>> the globally unique (issuer_id, user_id) pair. If the
>>>>>>>>>>>>> signature is based on PK, these tokens are also universally
>>>>>>>>>>>>> verifiable and fully portable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking forward to an interesting discussion,
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> --Breno
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Openid-specs-ab mailing list
>>>>>>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> --Breno
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Openid-specs-ab mailing list
>>>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> --Breno
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> --Breno
>>>>>>>> _______________________________________________
>>>>>>>> Openid-specs-ab mailing list
>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --Breno
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --Breno
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --Breno
>>>
>>>
>>
>>
>>
>> --
>> --Breno
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
--
--Breno
More information about the Openid-specs-ab
mailing list