[Openid-specs-ab] Identifiers and discovery.

Wed Apr 13 23:56:34 UTC 2011

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