[Openid-specs-ab] Identifiers and discovery.

Breno de Medeiros breno at google.com
Thu Apr 14 00:06:20 UTC 2011 

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.html>
>>>> and the OAuth JWT Profile
>>>> <http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html>
>>>> 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.html> ,
>>>> 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/005D0000001Az1u 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/005D0000001Az1u
>>>>
>>>>
>>>> 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/AIbEiAIAAABECOzLpfXm2dn7pAEiC3
>>>> ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThlZjQ3MmMx
>>>> 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ß20183lsk
>>>>> 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

More information about the Openid-specs-ab mailing list