[Openid-specs-ab] Identifiers and discovery.
Breno de Medeiros
breno at google.com
Thu Apr 14 00:54:25 UTC 2011
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.html>
>>>>>>>> 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.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.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/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/AIbEiAIAAABECOzLpfXm2dn7pA
>>>>>>>> E
>>>>>>>> iC3
>>>>>>>> ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThlZjQ3
>>>>>>>> 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ß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
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> --Breno
>>>
>>>
>>
>>
>>
>> --
>> --Breno
>
>
--
--Breno
More information about the Openid-specs-ab
mailing list