[Openid-specs-ab] Identifiers and discovery.
John Bradley
ve7jtb at ve7jtb.com
Thu Apr 14 00:04:53 UTC 2011
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.
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
More information about the Openid-specs-ab
mailing list