[Openid-specs-ab] Identifiers and discovery.
Chuck Mortimore
cmortimore at salesforce.com
Thu Apr 14 01:10:49 UTC 2011
On Apr 13, 2011, at 6:01 PM, "Mike Jones" <Michael.Jones at microsoft.com> wrote:
> Yes, that case is easy. But it makes other cases, where we *do* want to discover services for the principal harder, and inconsistent with the OpenID case. Better to use the same identifier string for all cases and have a simple rule for extracting the IdP substring from the Principal string than to use one identifier in some cases and another identifier for the same thing in other cases.
>
> The rule I was thinking of is dirt-simple: The IdP string is everything up to the last "/" in the Principal URL. It doesn't get much simpler than that.
For what it's worth, that algo would break my current deployment. I use tenant_id/user_id as the user identifier portion of my principal URL.
-cmort
>
> (Yes, the other possible dirt-simple rule is that the IdP is just the host component of the Principal URL. Discussion on which rule is better is welcome.)
>
> -- Mike
>
> -----Original Message-----
> From: Breno de Medeiros [mailto:breno at google.com]
> Sent: Wednesday, April 13, 2011 5:54 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: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/AIbEiAIAAABECOzLpfXm2dn
>>>>>>>>> 7pA
>>>>>>>>> E
>>>>>>>>> iC3
>>>>>>>>> ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThlZ
>>>>>>>>> jQ3
>>>>>>>>> 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
>
> _______________________________________________
> 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