[Openid-specs-ab] Identifiers and discovery.
Mike Jones
Michael.Jones at microsoft.com
Fri Apr 15 19:47:28 UTC 2011
SWD requests can be protected using standard HTTP authentication mechanisms. In particular, the GET can return a WWW-Authenticate response, etc. We don't need all of OAuth to protect discovery requests.
-- Mike
-----Original Message-----
From: John Bradley [mailto:ve7jtb at ve7jtb.com]
Sent: Friday, April 15, 2011 11:04 AM
To: Breno de Medeiros
Cc: Mike Jones; Chuck Mortimore; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Identifiers and discovery.
I agree that discovery of endpoints/services specific to a user should be protected.
I thought that was one of the goals of SWD but perhaps not.
I prefer not to have all of the URI hardcoded in the spec. I think that is a bit inflexible for deployers.
Given a user ID in email or URL we know how to do SWD discovery on it to get openID endpoints.
I still think having to make multiple requests is not ideal however.
We haven't sorted out what you do if you want the generic endpoints for a IdP if you don't have a userID.
Perhaps it is just sending a empty user? We should be able to agree on something.
Mike seems to want the principal in the JWT to be directly discoverable via SWD.
Others are OK with it being discoverable via SWD.
And there is a camp (perhaps only me) that thinks it should only be discoverable via Oauth protected endpoint.
The side issues are should it be one field or two and how is the JWT ID Token validated.
Having SWD be optionally OAuth protected could be one solution.
eg you may not be able to see all of the information if you don't pass in a access token.
People having to parse the Provider out of the User ID URL seems like it's going to create interoperability problems.
Are we assuming that you can't run two separate IdP on the same host name?
That wasn't a restriction in openID 2.0.
So is a issuer http://salesforce.com/ , https://company1.salesforce.com/ etc
Or are we going to allow
http://salesforce.com/company1/
How are we validating he issuer against the endpoints it is using.
The simple thing would be to pick the token endpoint and make that the issuer. RP verifies by an exact string match.
Not flexible for the IdP however. In SAML 2.0 that is why EntityID are separate identifiers from the protocol endpoints.
If the identifier for the IdP is not the token endpoint then we need to ether algorithmically determine it (eg the host part) or do discovery on it to link back to the endpoint or signature.
Having issuer and user combined makes parsing them apart hard if we have any ambiguity.
Leaving them separate in the assertion and combining them for discovery seems on the surface to cause the least issues for openID itself.
The question is if that identifier is concatenated and provided to 3rd parties as a discoverable identifier is that a problem?
John B.
On 2011-04-15, at 12:42 PM, Breno de Medeiros wrote:
> 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?endpoi
> nt=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.htm
>>>>>>>>>>> l> 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.h
>>>>>>>>>>> tm
>>>>>>>>>>> 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.htm
>>>>>>>>>>> l>
>>>>>>>>>>> , 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/005D0000001A
>>>>>>>>>>> z1
>>>>>>>>>>> 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/005D0000001A
>>>>>>>>>>> z1
>>>>>>>>>>> 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/AIbEiAIAAABECOzLpfXm
>>>>>>>>>>> 2d
>>>>>>>>>>> n
>>>>>>>>>>> 7pA
>>>>>>>>>>> E
>>>>>>>>>>> iC3
>>>>>>>>>>> ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OT
>>>>>>>>>>> hl
>>>>>>>>>>> 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ß20183
>>>>>>>>>>>> ls
>>>>>>>>>>>> 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