[Openid-specs-ab] Identifiers and discovery.
John Bradley
ve7jtb at ve7jtb.com
Thu Apr 14 00:12:50 UTC 2011
Yes I was referring to the case where there is no user identifier.
I just know the users IDP because they clicked on a Live button etc.
John B.
On 2011-04-13, at 8:11 PM, Mike Jones wrote:
>> (I don't know that we resolved how to discover a IdP in SWD.
>
> Edmund Jay has worked out a simple way to discover IdPs from user identifiers using SWD. I hope to see it posted to the list shortly! :-)
>
> -- Mike
>
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb at ve7jtb.com]
> Sent: Wednesday, April 13, 2011 4:58 PM
> To: Breno de Medeiros
> Cc: Mike Jones; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Identifiers and discovery.
>
> I think that we can probably agree that EnttiyID/Issuer names should be globally scoped.
> I also think they need to be discoverable for services. (I don't know that we resolved how to discover a IdP in SWD.
>
> The thing that we seem split on is if the non reassignable identifier needs to be publicly discoverable.
>
> In XRI one reason they were discoverable was they supported delegation of sub identifiers.
> Probably not something we want.
>
> However using iNumbers the non-reassignable ID were clearly separated from the user enterable reassignable ones.
>
> I do like the idea of using the user info endpoint for the user as the ID. However that prevents IdP from ever changing there endpoint URL.
>
> John B.
>
> On 2011-04-13, at 7:46 PM, Breno de Medeiros wrote:
>
>> 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/AIbEiAIAAABECOzLpfXm2dn7pAEiC
>>> 3ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThlZjQ3Mm
>>> MxMAH08_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
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
More information about the Openid-specs-ab
mailing list