Hi guys, <div><br></div><div>sorry for jumping in late on the thread - I hope I got the gist of it by skimming through the posts. </div><div><br></div><div>As far as I can tell, here is what people agree on:</div><div><br>
</div><div>- the user identifier that clients derive from a JWT must be globally unique</div><div>- there shouldn't be any kind of "discovery" the client needs to perform (i.e., making network requests) to find out whether the user identifier is well-formed (as they currently have to do in OpenID).</div>
<div><br></div><div>What people don't agree on is whether the userid in the JWT itself should be globally unique, or whether the client constructs the globally-unique user id from the JWT through some procedure. </div>
<div><br></div><div>Am I right so far?</div><div><br></div><div>In either case, the client will have to do _some_ sort of work: If the uid is already globally unique, then the client needs to perform checks to make sure that the uid is well-formed. For example, we could decide (as a strawman) that the uid MUST be of type "issuer" "@" "some-unique-postfix". Then the client would have to make sure the uid's prefix equals the issuer. </div>
<div><br></div><div>If the uid is not already unique, then the client does some slightly different work. Again, as a strawman, this could be: userid = JWT.issuer + "@" + JWT.uid</div><div><br></div><div>These two approaches seem pretty much equivalent to me, and I have a hard time believing that there are use cases that one can't address while the other can. Aesthetically, I find the latter more pleasing: it doesn't repeat information in the JWT, so my vote would be for that.</div>
<div><br></div><div>Dirk.</div><div><br><div class="gmail_quote">On Thu, Apr 14, 2011 at 12:34 PM, Chuck Mortimore <span dir="ltr"><<a href="mailto:cmortimore@salesforce.com">cmortimore@salesforce.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
<font face="Lucida Grande"><span style="font-size:11pt">Agreed – we don’t want discovery happing in the middle of an authentication flow. The IDP is known at this phase<br>
<br>
-cmort<div><div></div><div class="h5"><br>
<br>
<br>
On 4/13/11 5:12 PM, "Breno de Medeiros" <<a href="http://breno@google.com" target="_blank">breno@google.com</a>> wrote:<br>
<br>
</div></div></span></font><div><div></div><div class="h5"><blockquote><font face="Lucida Grande"><span style="font-size:11pt">On Wed, Apr 13, 2011 at 17:11, Mike Jones <<a href="http://Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> wrote:<br>
>> (I don't know that we resolved how to discover a IdP in SWD.<br>
><br>
> 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! :-)<br>
<br>
It still begs the question of why discovery is needed here. In which<br>
way authentication benefits from discoverable identifiers? If<br>
discovery is required for completion of the authentication step at the<br>
very minimum it adds latency.<br>
<br>
><br>
> -- Mike<br>
><br>
> -----Original Message-----<br>
> From: John Bradley [<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">mailto:ve7jtb@ve7jtb.com</a>]<br>
> Sent: Wednesday, April 13, 2011 4:58 PM<br>
> To: Breno de Medeiros<br>
> Cc: Mike Jones; <a href="http://openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
> Subject: Re: [Openid-specs-ab] Identifiers and discovery.<br>
><br>
> I think that we can probably agree that EnttiyID/Issuer names should be globally scoped.<br>
> I also think they need to be discoverable for services. (I don't know that we resolved how to discover a IdP in SWD.<br>
><br>
> The thing that we seem split on is if the non reassignable identifier needs to be publicly discoverable.<br>
><br>
> In XRI one reason they were discoverable was they supported delegation of sub identifiers.<br>
> Probably not something we want.<br>
><br>
> However using iNumbers the non-reassignable ID were clearly separated from the user enterable reassignable ones.<br>
><br>
> 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.<br>
><br>
> John B.<br>
><br>
> On 2011-04-13, at 7:46 PM, Breno de Medeiros wrote:<br>
><br>
>> You can have a global federation with IDP-scoped user identifiers, as<br>
>> long as the IDP/issuer names are global in scope.<br>
>><br>
>> On Wed, Apr 13, 2011 at 16:40, Mike Jones <<a href="http://Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> wrote:<br>
>>> I agree that uniqueness is only required within the federation. But<br>
>>> if you adopt the OpenID Foundation's position that we are trying to<br>
>>> build open systems where any party can be a full participant, then<br>
>>> one of the things that our architecture needs to support is precisely a global federation.<br>
>>> (And yes, of course, being a full participant in any particular<br>
>>> context requires that the party is appropriately trusted by the other<br>
>>> parties with which it is interacting.) But before trust can be<br>
>>> established, the first step is being able to identify and perform<br>
>>> discovery on the participants in the global federation to discover<br>
>>> their services that you need to interact with.<br>
>>><br>
>>><br>
>>><br>
>>> I obviously agree with you that any TRUST decision based on a claim<br>
>>> must be based upon the issuer of that claim. But that's actually<br>
>>> independent of whether the IDENTIFIER for a principal (which yes,<br>
>>> would be used in a claim signed by an issuer) is globally unique or not.<br>
>>><br>
>>><br>
>>><br>
>>> -- Mike<br>
>>><br>
>>><br>
>>><br>
>>> From: Chuck Mortimore [<a href="mailto:cmortimore@salesforce.com" target="_blank">mailto:cmortimore@salesforce.com</a>]<br>
>>> Sent: Wednesday, April 13, 2011 4:31 PM<br>
>>><br>
>>> To: Mike Jones; <a href="http://Axel.Nennker@telekom.de" target="_blank">Axel.Nennker@telekom.de</a>; <a href="http://breno@google.com" target="_blank">breno@google.com</a><br>
>>> Cc: <a href="http://openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.<br>
>>><br>
>>><br>
>>><br>
>>> On 4/13/11 4:10 PM, "Mike Jones" <<a href="http://Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> wrote:<br>
>>><br>
>>> Taking your viewpoint for a minute, yes, in SWD the principal will of<br>
>>> course be interpreted by the site at which discovery is being<br>
>>> performed. This somewhat corresponds to it being relative to an issuer, I suppose.<br>
>>><br>
>>> It really must be interpreted in the context of the issuer, else<br>
>>> you'd have issuers asserting principals for which they are not authoritative.<br>
>>><br>
>>> As a thought experiment, are you also proposing that an audience<br>
>>> value could/should also be similarly scoped in some manner?<br>
>>><br>
>>> In federation deployments, the issuer and audience must be unique within the<br>
>>> federation. It's not mandatory that they are globally unique. We could<br>
>>> go for a global federation here which would change that, but I<br>
>>> suspect that would actually limit some use-cases.<br>
>>><br>
>>> And do you agree with my architectural statement that the same entity<br>
>>> could be any of a principal, an issuer, or an audience restriction<br>
>>> value? If so, the your statement that an issuer should be unique<br>
>>> also implies that so should a principal and an audience restriction<br>
>>> value, as they are logically of the same kind.<br>
>>><br>
>>> I agree that an entity may be playing multiple roles, however we<br>
>>> always need to interpret a claim in the context of who is making it.<br>
>>><br>
>>> For example, at Salesforce I can act as both a SAML SP and a SAML IDP. If<br>
>>> a customer passes me an assertion I create session for the subject relative<br>
>>> to the issuer, and check to see if the audience is me. If I turn around<br>
>>> and act as an IDP, the entity id I previously used for audience now<br>
>>> becomes my issuer, and I may send the exact same subject. However,<br>
>>> the receiving service provider needs to interpret that subject as relative to me, and not<br>
>>> the original IDP, as I'm the one making the assertion. It would<br>
>>> technically be possible to form multi-party claims, or to pass along<br>
>>> claims, but in all cases you must consider the subject in the light<br>
>>> of who's making the assertion.<br>
>>><br>
>>> Note this isn't yet arguing for or against separating them :-)<br>
>>><br>
>>> -cmort<br>
>>><br>
>>> Thanks for the thoughtful discussion.<br>
>>><br>
>>> -- Mike<br>
>>><br>
>>><br>
>>> From: Chuck Mortimore [<a href="mailto:cmortimore@salesforce.com" target="_blank">mailto:cmortimore@salesforce.com</a>]<br>
>>> Sent: Wednesday, April 13, 2011 4:03 PM<br>
>>> To: Mike Jones; <a href="http://Axel.Nennker@telekom.de" target="_blank">Axel.Nennker@telekom.de</a>; <a href="http://breno@google.com" target="_blank">breno@google.com</a><br>
>>> Cc: <a href="http://openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.<br>
>>><br>
>>> When I said JWT I guess I actually meant JWT bearer token. You are correct<br>
>>> that JWT on it's own doesn't contain a principal.<br>
>>><br>
>>> I agree that Issuer should be unique and is in JWT, SAML, etc. In<br>
>>> practice, it's pretty difficult to enforce global uniqueness of this<br>
>>> without some sort of discovery.<br>
>>><br>
>>> I do not believe that the text of your JWT Bearer Token profile makes "prn"<br>
>>> globally unique, nor do I think that it should. The identifier should<br>
>>> always be scoped to the issuer. The result may be globally unique,<br>
>>> but prn should always be interpreted in context of who's asserting it.<br>
>>><br>
>>> -cmort<br>
>>><br>
>>><br>
>>> On 4/13/11 3:04 PM, "Mike Jones" <<a href="http://Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> wrote:<br>
>>> No, I don't believe that captures it accurately, as JWT<br>
>>> <<a href="http://self-issued.info/docs/draft-jones-json-web-token.html" target="_blank">http://self-issued.info/docs/draft-jones-json-web-token.html</a>> does<br>
>>> not follow the first model as you wrote below. Both SWD<br>
>>> <<a href="http://self-issued.info/docs/draft-jones-simple-web-discovery.html" target="_blank">http://self-issued.info/docs/draft-jones-simple-web-discovery.html</a>><br>
>>> and the OAuth JWT Profile<br>
>>> <<a href="http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html" target="_blank">http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html</a>><br>
>>> assume that the principal is a globally unique identifier. Likewise,<br>
>>> all three of JWT<br>
>>> <<a href="http://self-issued.info/docs/draft-jones-json-web-token.html" target="_blank">http://self-issued.info/docs/draft-jones-json-web-token.html</a>> , SWD<br>
>>> <<a href="http://self-issued.info/docs/draft-jones-simple-web-discovery.html" target="_blank">http://self-issued.info/docs/draft-jones-simple-web-discovery.html</a>><br>
>>> , and the OAuth JWT Profile<br>
>>> <<a href="http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html" target="_blank">http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html</a>> assume that issuer is also a globally unique identifier.<br>
>>><br>
>>> Furthermore, architecturally, a principal in one context may be an<br>
>>> issuer in another context and an audience restriction value in a<br>
>>> third. All need to use the same data representation for the system<br>
>>> to architecturally hang together.<br>
>>><br>
>>> I believe that this is a strong architectural argument why<br>
>>> <a href="https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u" target="_blank">https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u</a> is<br>
>>> the best choice.<br>
>>><br>
>>> -- Mike<br>
>>><br>
>>><br>
>>> From: <a href="http://openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a><br>
>>> [<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Chuck<br>
>>> Mortimore<br>
>>> Sent: Wednesday, April 13, 2011 2:43 PM<br>
>>> To: <a href="http://Axel.Nennker@telekom.de" target="_blank">Axel.Nennker@telekom.de</a>; <a href="http://breno@google.com" target="_blank">breno@google.com</a><br>
>>> Cc: <a href="http://openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.<br>
>>><br>
>>> I'd be concerned treating either 2 or 3 as an Identitfier.<br>
>>><br>
>>> As I understand it, the main debate is around the persistent<br>
>>> identifier, and if the issuer and principal are separate entities or if the issuer is<br>
>>> reflected in the principal. For example do we want<br>
>>> issuer: <a href="https://login.salesforce.com/id" target="_blank">https://login.salesforce.com/id</a><br>
>>> principal: 00DD0000000FH8l/005D0000001Az1u<br>
>>><br>
>>> Or<br>
>>> principal:<br>
>>> <a href="https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u" target="_blank">https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u</a><br>
>>><br>
>>><br>
>>> The current ConnectCore uses the first model ( calling them user_id and<br>
>>> domain ). JWT and SAML follow the first model. I believe this is Breno's<br>
>>> preference as well.<br>
>>><br>
>>> We've currently deployed the second model; our focus was on<br>
>>> simplicity and discoverability of the data behind the service. It<br>
>>> acts are both our user_info endpoint as well as a discovery service<br>
>>> for endpoints authorized for the access_token.<br>
>>><br>
>>> Does this capture it accurately? Is so, let's just hash out the pros/cons<br>
>>> of each approach. I'm loathe to starting issuing 3 different types of<br>
>>> identifiers.<br>
>>><br>
>>> -cmort<br>
>>><br>
>>><br>
>>><br>
>>> On 4/13/11 1:53 AM, "<a href="http://Axel.Nennker@telekom.de" target="_blank">Axel.Nennker@telekom.de</a>"<br>
>>> <<a href="http://Axel.Nennker@telekom.de" target="_blank">Axel.Nennker@telekom.de</a>><br>
>>> wrote:<br>
>>> You say:<br>
>>> 1) Persistent Identifier (in the scope of the OP), never reassigned<br>
>>> lasjkflasdflsajfljal02384ß20183lskadjfölsafj<br>
>>><br>
>>> 2) UI Identifier<br>
>>> Fullname: Axel Nennker<br>
>>> Profilepicref:<br>
>>> <a href="https://www.google.com/s2/photos/public/AIbEiAIAAABECOzLpfXm2dn7pAEiC" target="_blank">https://www.google.com/s2/photos/public/AIbEiAIAAABECOzLpfXm2dn7pAEiC</a><br>
>>> 3ZjYXJkX3Bob3RvKihiODRmYjAxMDU0ZjdhYmVmMzI4MGZmN2I0ZWI4NWY1OThlZjQ3Mm<br>
>>> MxMAH08_TJz4ElY-WIBPBE1pmNuOStyQ<br>
>>> (is this persistent?)<br>
>>><br>
>>> 3) Contact Identifier<br>
>>> Work: <a href="http://axel.nennker@telekom.de" target="_blank">axel.nennker@telekom.de</a><br>
>>> Private: <a href="http://ignisvulpis@gmail.com" target="_blank">ignisvulpis@gmail.com</a><br>
>>> Personal: <a href="http://axel@nennker.de" target="_blank">axel@nennker.de</a><br>
>>> Tel: +491702275312<br>
>>><br>
>>> Right?<br>
>>><br>
>>> Is <a href="https://www.google.com/profiles/ignisvulpis" target="_blank">https://www.google.com/profiles/ignisvulpis</a> in category 1? Never<br>
>>> reassigned?<br>
>>><br>
>>>> -----Original Message-----<br>
>>>> From: Breno de Medeiros [<a href="mailto:breno@google.com" target="_blank">mailto:breno@google.com</a>]<br>
>>>> Sent: Wednesday, April 13, 2011 10:38 AM<br>
>>>> To: Nennker, Axel<br>
>>>> Cc: <a href="http://openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
>>>> Subject: Re: [Openid-specs-ab] Identifiers and discovery.<br>
>>>><br>
>>>> On Wed, Apr 13, 2011 at 01:15, <<a href="http://Axel.Nennker@telekom.de" target="_blank">Axel.Nennker@telekom.de</a>> wrote:<br>
>>>>><br>
>>>>> Similar for me. I gave up on trying to attend because 4pm<br>
>>>> PT is 1am here, so I went to sleep at 23:30 and could have made it<br>
>>>> for midnight.<br>
>>>>> Anyway.<br>
>>>>><br>
>>>>> Regarding identifiers: Some people expect that the openid<br>
>>>> is "fancy" and easy to distiguish.<br>
>>>>> Example: @t is much cooler than @AxelNennker or <a href="http://pt@fb.com" target="_blank">pt@fb.com</a><br>
>>>> is cooler than <a href="http://user4711@facebook.com" target="_blank">user4711@facebook.com</a> or<br>
>>>>> <a href="https://me.google.com/AxelNennker" target="_blank">https://me.google.com/AxelNennker</a> is cooler than<br>
>>>> <a href="https://me.google.com/users/lasjkflasdflsajfljal02384ß20183lsk" target="_blank">https://me.google.com/users/lasjkflasdflsajfljal02384ß20183lsk</a><br>
>>>> adjfölsafj<br>
>>>>><br>
>>>>> The uglier ones achieve the goal of beeing not reassigned<br>
>>>> much easier than the prettier ones.<br>
>>>>><br>
>>>>> Display Names are an related issue: I guess that there are<br>
>>>> more than one "Mike Jones" in Microsoft possibly even more than one<br>
>>>> "Michael B. Jones". Each has a unique identifier which might be<br>
>>>> reassigned (after a grace period) to a new Michael B. Jones.<br>
>>>>><br>
>>>>> This is not only a technical problem. People want the<br>
>>>> pretty identifiers.<br>
>>>><br>
>>>> It is a technical problem. If we label the identifiers in the<br>
>>>> protocol as:<br>
>>>><br>
>>>> - Identifier 1: This is persistent. Use as index in your DB. E.g: a<br>
>>>> numeric value.<br>
>>>> - Identifier 2: This is what the user wants you to represent him as.<br>
>>>> E.g: a name, photo, business card, etc.<br>
>>>> - Identifier 3: This is what the user thinks you can use to find who<br>
>>>> he is. E.g.: an email address<br>
>>>><br>
>>>>> The best we can achieve, I think, is that users never see<br>
>>>> the unique, never reassigned (, maybe global) identifiers.<br>
>>>>> And that the UI for the display names is powerfull enough<br>
>>>> to help me to find the Mike Jones I want to reach.<br>
>>>>><br>
>>>>> Example: Consider a blog post with comments by openid<br>
>>>> users. The blog received a sreg fullname and the openid.claimed_id<br>
>>>> and openid.identity.<br>
>>>>> Now it renders the fullname on the html page giving us<br>
>>>> comment by several Mike Jones. The "social" rendering would allow my<br>
>>>> user agent to render the comments from my friend list other than<br>
>>>> comments from people I don't know.<br>
>>>>><br>
>>>>> Ok, this moves away from pure protocol issues and issuer<br>
>>>> policy to OC best practices and UI issues.<br>
>>>>> I am not sure how the openid abc wg "protocol" group can<br>
>>>> solve this non technical problems.<br>
>>>>><br>
>>>><br>
>>>> No, that's the mistake OpenID2 fell into. We should have different<br>
>>>> identifiers for different purposes so that it's foolproof how to<br>
>>>> deal with this.<br>
>>>><br>
>>>> My proposal is that the identifier used in auth is number 1. You<br>
>>>> know you can't use to do anything presentational with it.<br>
>>>> Identifier #2 is the easiest: we return attributes at the user info<br>
>>>> endpoint that can be used to personalize the user experience.<br>
>>>> Identifier #3 is missing from the current drafts. I can see two<br>
>>>> sensible approaches:<br>
>>>><br>
>>>> - Define a discovery protocol that starts by going to the issuer and<br>
>>>> asking what it knows about the asserted user_id. The advantage of<br>
>>>> doing this is that we can support both public and protected (meaning<br>
>>>> that user needs to consent) discovery with the same set of techniques.<br>
>>>><br>
>>>> - Use the email or profile URL (both which will be returned as user<br>
>>>> attributes) as discovery starting points. This has some advantages<br>
>>>> in that we may be able to re-use some existing ideas and techniques.<br>
>>>><br>
>>>> Again, what we don't want is an identifier that does all three jobs<br>
>>>> poorly.<br>
>>>><br>
>>>>> -Axel<br>
>>>>><br>
>>>>>> -----Original Message-----<br>
>>>>>> From: <a href="http://openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a><br>
>>>>>> [<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of<br>
>>>>>> Breno de Medeiros<br>
>>>>>> Sent: Tuesday, April 12, 2011 6:18 PM<br>
>>>>>> To: <a href="http://openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
>>>>>> Subject: [Openid-specs-ab] Identifiers and discovery.<br>
>>>>>><br>
>>>>>> I hope Nat's well.<br>
>>>>>><br>
>>>>>> I was in a meeting at 3:00pm (that I scheduled after<br>
>>>> JBradley asserted<br>
>>>>>> the conference call would take place as usual at 4pm).<br>
>>>> When I joined,<br>
>>>>>> Mike Jones and Nat were dropping off the call.<br>
>>>>>><br>
>>>>>> That left JBradley and I on the call. We had a discussion on<br>
>>>>>> identifiers and discovery.<br>
>>>>>><br>
>>>>>> I would like to continue this conversation via email, as it's an<br>
>>>>>> important one.<br>
>>>>>><br>
>>>>>><br>
>>>>>> Currently, Google's proposal on identifiers is:<br>
>>>>>><br>
>>>>>> - Identifiers are unique to the user and non-reassignable<br>
>>>> within the<br>
>>>>>> scope of the issuer. However, they need not be globally unique.<br>
>>>>>><br>
>>>>>> - Id_tokens attest to the issuer and therefore provide a<br>
>>>> statement of<br>
>>>>>> the globally unique (issuer_id, user_id) pair. If the signature is<br>
>>>>>> based on PK, these tokens are also universally verifiable and<br>
>>>>>> fully portable.<br>
>>>>>><br>
>>>>>> Looking forward to an interesting discussion,<br>
>>>>>><br>
>>>>>> --<br>
>>>>>> --Breno<br>
>>>>>> _______________________________________________<br>
>>>>>> Openid-specs-ab mailing list<br>
>>>>>> <a href="http://Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
>>>>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>>>>>><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> --Breno<br>
>>>><br>
>>> _______________________________________________<br>
>>> Openid-specs-ab mailing list<br>
>>> <a href="http://Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> --Breno<br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="http://Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
><br>
><br>
<br>
<br>
<br>
--<br>
--Breno<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="http://Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
</span></font></blockquote>
</div></div></div>
<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br></div>