[Openid-specs-ab] Identifiers and discovery.
Mike Jones
Michael.Jones at microsoft.com
Thu Apr 14 00:15:51 UTC 2011
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.
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
More information about the Openid-specs-ab
mailing list