+1 Phil
@independentid www.independentid.com phil.h...@oracle.com On Jul 24, 2014, at 10:25 AM, John Bradley <ve7...@ve7jtb.com> wrote: > I am not against discussion in the WG. > > I happen to agree with Phil's fundamental premise that some developers are > using OAuth in a insecure way to do authentication. > > That raises the question of how to best educate them, and or address > technical barriers. > > It is on the second point that people's opinions seem to divide. > > Some people thing that if we have a OAuth flow that eliminates the access > token (primarily to avoid asking for consent as I understand it) and just > return a id_token from the token endpoint that can be done in a spec short > enough to het people to read. The subtext of this is that the Connect > specification is too large that it scare people, and they don't find the > spec in the first place because it is not a RFC. > > An other common possession is that if you don't want to prompt the user for > consent then don't ask for scopes. Twisting the OAuth spec to not return an > access token is not OAuth, yes you could use a different endpoint rather > than the token endpoint, but that is not OAuth. Connect was careful not to > break the OAuth spec. As long as you are willing to take a access token > with no scopes (the client needs to understand that there are no attributes > one way or another anyway or it will break) then you don't need to change > OAuth. You can publish a profile of connect that satisfies the use case. > > I think Mike has largely done that but it might be better being less stingy > on references back to the larger spec. > > The questions are do we modify OAuth to not return an access token, and if so > how, and if we do is it still OAuth. > > The other largely separable question is do we create confusion in the market > and slow the the adoption of identity federation on top of OAuth, or find a > way to make this look like a positive alignment of interests around a subset > of Connect. > > There are a number of options. > 1: We can do a profile in the OIDF and publish it as a IETF document. > Perhaps the cleanest from an IPR point of view. > 2:We can do a profile in the OAuth WG referencing connect. > 3:We can do a AD sponsored profile that is not in the OAuth WG. > 4:We can do a small spec in OAuth to add response_type to the token endpoint. > in combination with 1, 2, or 3 > > I agree that stoping developers doing insecure things needs to be addressed > somehow. > I am not personally convinced that Oauth without access tokens is sensible. > > Looking forward to the meeting:) > > John B. > On Jul 24, 2014, at 6:52 AM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > >> I'd note that the reaction at the conference to Ian's statement was >> overwhelmingly positive. There was a wide range of industry people here - >> implementers, practitioners, deployers, strategists, etc. - and it seems >> pretty clear that the "rough consensus" of the industry at large is that a4c >> is not wanted or needed. >> >> >> On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <sakim...@gmail.com> wrote: >> And here is a quote from Ian's blog. >> >> And although the authentication wheel is round, that doesn’t mean it isn’t >> without its lumps. First, we do see some reinventing the wheel just to >> reinvent the wheel. OAuth A4C is simply not a fruitful activity and should >> be put down. >> >> (Source) >> http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html >> >> >> 2014-07-23 16:53 GMT-04:00 John Bradley <ve7...@ve7jtb.com>: >> >> I thought I did post this to the list. >> >> I guess I hit the wrong reply on my phone. >> >> John B. >> Sent from my iPhone >> >> On Jul 23, 2014, at 4:50 PM, tors...@lodderstedt.net wrote: >> >>> we are two, at least :-) >>> >>> Why didn't you post this on the list? >>> >>> When will be be arriving? >>> >>> Am 23.07.2014 16:39, schrieb John Bradley: >>> >>>> Ian Glazer mentioned this in his keynote at CIS yesterday. >>>> >>>> His advice was please stop, we are creating confusion and uncertainty. >>>> >>>> We are becoming our own wort enemy. ( my view though Ian may share it) >>>> >>>> Returning just an id_ token from the token endpoint has little real value. >>>> >>>> Something really useful to do would be sorting out channel_id so we can do >>>> PoP for id tokens to make them and other cookies secure in the front >>>> channel. I think that is a better use of time. >>>> >>>> I may be in the minority opinion on that, it won't be the first time. >>>> >>>> >>>> John B. >>>> Sent from my iPhone >>>> >>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <tors...@lodderstedt.net> >>>> wrote: >>>> >>>>> You are right from a theoretical perspective. Practically this was caused >>>>> by editorial decisions during the creation of the RFC. As far as I >>>>> remember, there was a definition of the (one) token endpoint response in >>>>> early versions. No one every considered to NOT respond with an access >>>>> token from the token endpoint. So one might call it an implicit >>>>> assumption. >>>>> >>>>> I'm worried that people get totally confused if an exception is >>>>> introduced now given the broad adoption of OAuth based on this assumption. >>>>> >>>>> regards, >>>>> Torsten. >>>>> >>>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.bro...@gmail.com>: >>>>> >>>>>> Is it said anywhere that ALL grant types MUST use Section 5.1 responses? >>>>>> Each grant type references Section 5.1, and "access token request" is >>>>>> only defined in the context of the defined grant types. Section 2.2 >>>>>> doesn't talk about the request or response format. >>>>>> >>>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" <sakim...@gmail.com> a écrit : >>>>>> Is it? Apart from the implicit grant that does not use token endpoint, >>>>>> all other grant references section 5.1 for the response, i.e., all >>>>>> shares the same response. >>>>>> >>>>>> >>>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer <t.bro...@gmail.com>: >>>>>> I hadn't realized the JSON response that requires the access_token field >>>>>> is defined per grant_type, so I'd be OK to "extend the semantics" as in >>>>>> the current draft. >>>>>> That was actually my main concern: that the token endpoint mandates >>>>>> access_token; but its actually not the case. >>>>>> >>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" <sakim...@gmail.com> a écrit : >>>>>> >>>>>> I agree with John that overloading response_type @ authz endpoint is a >>>>>> bad idea. It completely changes the semantics of this parameter. NOTE: >>>>>> what I was proposing was not this parameter, but a new parameter >>>>>> response_type @ token endpoint. >>>>>> >>>>>> I also think overloading grant_type is a bad idea since it changes its >>>>>> semantics. I quote the definition here again: >>>>>> >>>>>> grant >>>>>> credential representing the resource owner's authorization >>>>>> >>>>>> grant_type >>>>>> type of grant sent to the token endpoint to obtain the access token >>>>>> >>>>>> It is not about controlling what is to be returned from the token >>>>>> endpoint, but the hint to the token endpoint describing the type of >>>>>> credential the endpoint has received. It seems the "control of what is >>>>>> being returned from token endpoint" is just a side effect. >>>>>> >>>>>> I am somewhat ambivalent[1] in changing the semantics of token endpoint, >>>>>> but in as much as "text is the king" for a spec., we probably should not >>>>>> change the semantics of it as Torsten points out. If it is ok to change >>>>>> this semantics, I believe defining a new parameter to this endpoint to >>>>>> control the response would be the best way to go. This is what I have >>>>>> described previously. >>>>>> >>>>>> Defining a new endpoint to send code to get ID Token and forbidding the >>>>>> use of it against token endpoint would not change the semantics of any >>>>>> existing parameter or endpoint, which is good. However, I doubt if it is >>>>>> not worth doing. What's the point of avoiding access token scoped to >>>>>> UserInfo endpoint after all? Defining a new endpoint for just avoiding >>>>>> the access token for userinfo endpoint seems way too much the heavy wait >>>>>> way and it breaks interoperabiliy: it defeats the purpose of >>>>>> standardization. >>>>>> >>>>>> I have started feeling that no change is the best way out. >>>>>> >>>>>> Nat >>>>>> >>>>>> [1] If instead of saying "Token endpoint - used by the client to >>>>>> exchange an authorization grant for an access token, typically with >>>>>> client authentication", it were saying "Token endpoint - used by the >>>>>> client to exchange an authorization grant for tokens, typically with >>>>>> client authentication", then it would have been OK. It is an expansion >>>>>> of the capability rather than changing the semantics. >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones <michael.jo...@microsoft.com>: >>>>>> You need the alternative response_type value ("code_for_id_token" in the >>>>>> A4C draft) to tell the Authorization Server to return a code to be used >>>>>> with the new grant type, rather than one to use with the >>>>>> "authorization_code" grant type (which is what response_type=code does). >>>>>> >>>>>> >>>>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley >>>>>> Sent: Wednesday, July 23, 2014 10:33 AM >>>>>> To: tors...@lodderstedt.net >>>>>> >>>>>> >>>>>> Cc: oauth@ietf.org >>>>>> Subject: Re: [OAUTH-WG] New Version Notification for >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>> >>>>>> >>>>>> If we use the token endpoint then a new grant_type is the best way. >>>>>> >>>>>> >>>>>> It sort of overloads code, but that is better than messing with >>>>>> response_type for the authorization endpoint to change the response from >>>>>> the token_endpoint. That is in my opinion a champion bad idea. >>>>>> >>>>>> >>>>>> In discussions developing Connect we decided not to open this can of >>>>>> worms because no good would come of it. >>>>>> >>>>>> >>>>>> The token_endpoint returns a access token. Nothing requires scope to be >>>>>> associates with the token. >>>>>> >>>>>> >>>>>> That is the best solution. No change required. Better interoperability >>>>>> in my opinion. >>>>>> >>>>>> >>>>>> Still on my way to TO, getting in later today. >>>>>> >>>>>> >>>>>> John B. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 12:15 PM, tors...@lodderstedt.net wrote: >>>>>> >>>>>> The "response type" of the token endpoint is controlled by the value of >>>>>> the parameter "grant_type". So there is no need to introduce a new >>>>>> parameter. >>>>>> >>>>>> wrt to a potential "no_access_token" grant type. I do not consider this >>>>>> a good idea as it changes the semantics of the token endpoint (as >>>>>> already pointed out by Thomas). This endpoint ALWAYS responds with an >>>>>> access token to any grant type. I therefore would prefer to use another >>>>>> endpoint for the intended purpose. >>>>>> >>>>>> regards, >>>>>> Torsten. >>>>>> >>>>>> >>>>>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>>>> >>>>>> IMHO, changing the semantics of "response_type" @ authz endpoint this >>>>>> way is not a good thing. >>>>>> >>>>>> >>>>>> Instead, defining a new parameter "response_type" @ token endpoint, as I >>>>>> described in my previous message, >>>>>> >>>>>> probably is better. At least, it does not change the semantics of the >>>>>> parameters of RFC6749. >>>>>> >>>>>> >>>>>> Nat >>>>>> >>>>>> >>>>>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.bro...@gmail.com>: >>>>>> >>>>>> No, I mean response_type=none and response_type=id_token don't generate >>>>>> a code or access token so you don't use the Token Endpoint (which is not >>>>>> the same as the Authentication Endpoint BTW). >>>>>> >>>>>> With response_type=code_for_id_token, you get a code and exchange it for >>>>>> an id_token only, rather than an access_token, so you're changing the >>>>>> semantics of the Token Endpoint. >>>>>> >>>>>> >>>>>> I'm not saying it's a bad thing, just that you can't really compare none >>>>>> and id_token with code_for_id_token. >>>>>> >>>>>> >>>>>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. <jric...@mitre.org> >>>>>> wrote: >>>>>> >>>>>> It's only "not using the token endpoint" because the token endpoint >>>>>> copy-pasted and renamed the authentication endpoint. >>>>>> >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.bro...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Except that these are about not using the Token Endpoint at all, whereas >>>>>> the current proposal is about the Token Endpoint not returning an >>>>>> access_token field in the JSON. >>>>>> >>>>>> >>>>>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones >>>>>> <michael.jo...@microsoft.com> wrote: >>>>>> >>>>>> The response_type "none" is already used in practice, which returns no >>>>>> access token. It was accepted by the designated experts and registered >>>>>> in the IANA OAuth Authorization Endpoint Response Types registry at >>>>>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint. >>>>>> The registered "id_token" response type also returns no access token. >>>>>> >>>>>> >>>>>> So I think the question of whether response types that result in no >>>>>> access token being returned are acceptable within OAuth 2.0 is already >>>>>> settled, as a practical matter. Lots of OAuth implementations are >>>>>> already using such response types. >>>>>> >>>>>> >>>>>> -- Mike >>>>>> >>>>>> >>>>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt >>>>>> Sent: Wednesday, July 23, 2014 7:09 AM >>>>>> To: Nat Sakimura >>>>>> Cc: <oauth@ietf.org> >>>>>> Subject: Re: [OAUTH-WG] New Version Notification for >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>> >>>>>> >>>>>> Yes. This is why it has to be discussed in the IETF. >>>>>> >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> @independentid >>>>>> >>>>>> www.independentid.com >>>>>> >>>>>> phil.h...@oracle.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakim...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> Reading back the RFC6749, I am not sure if there is a good way of >>>>>> suppressing access token from the response and still be OAuth. It will >>>>>> break whole bunch of implicit definitions like: >>>>>> >>>>>> >>>>>> authorization server >>>>>> The server issuing access tokens to the client after successfully >>>>>> authenticating the resource owner and obtaining authorization. >>>>>> >>>>>> >>>>>> After all, OAuth is all about issuing access tokens. >>>>>> >>>>>> >>>>>> Also, I take back my statement on the grant type in my previous mail. >>>>>> >>>>>> >>>>>> The definition of grant and grant_type are respectively: >>>>>> >>>>>> >>>>>> grant >>>>>> >>>>>> credential representing the resource owner's authorization >>>>>> >>>>>> >>>>>> grant_type >>>>>> >>>>>> (string representing the) type of grant sent to the token endpoint >>>>>> to obtain the access token >>>>>> >>>>>> >>>>>> Thus, the grant sent to the token endpoint in this case is still 'code'. >>>>>> >>>>>> >>>>>> Response type on the other hand is not so well defined in RFC6749, but >>>>>> it seems it is representing what is to be returned from the >>>>>> authorization endpoint. To express what is to be returned from token >>>>>> endpoint, perhaps defining a new parameter to the token endpoint, which >>>>>> is a parallel to the response_type to the Authorization Endpoint seems >>>>>> to be a more symmetric way, though I am not sure at all if that is going >>>>>> to be OAuth any more. One straw-man is to define a new parameter called >>>>>> response_type to the token endpoint such as: >>>>>> >>>>>> >>>>>> response_type >>>>>> >>>>>> OPTIONAL. A string representing what is to be returned from the >>>>>> token endpoint. >>>>>> >>>>>> >>>>>> Then define the behavior of the endpoint according to the values as the >>>>>> parallel to the multi-response type spec. >>>>>> >>>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>> >>>>>> >>>>>> Nat >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.h...@oracle.com>: >>>>>> >>>>>> The draft is very clear. >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 0:46, Nat Sakimura <sakim...@gmail.com> wrote: >>>>>> >>>>>> The new grant type that I was talking about was >>>>>> >>>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", so to >>>>>> speak. >>>>>> >>>>>> It does not return anything per se, but an extension can define >>>>>> something on top of it. >>>>>> >>>>>> >>>>>> Then, OIDC can define a binding to it so that the binding only returns >>>>>> ID Token. >>>>>> >>>>>> This binding work should be done in OIDF. Should there be such a grant >>>>>> type, >>>>>> >>>>>> it will be an extremely short spec. >>>>>> >>>>>> >>>>>> At the same time, if any other specification wanted to define >>>>>> >>>>>> other type of tokens and have it returned from the token endpoint, >>>>>> >>>>>> it can also use this grant type. >>>>>> >>>>>> >>>>>> If what you want is to define a new grant type that returns ID Token >>>>>> only, >>>>>> >>>>>> then, I am with Justin. Since "other response than ID Token" is only >>>>>> >>>>>> theoretical, this is a more plausible way forward, I suppose. >>>>>> >>>>>> >>>>>> Nat >>>>>> >>>>>> >>>>>> 2014-07-22 14:30 GMT-04:00 Justin Richer <jric...@mit.edu>: >>>>>> >>>>>> So the draft would literally turn into: >>>>>> >>>>>> "The a4c response type and grant type return an id_token from the token >>>>>> endpoint with no access token. All parameters and values are defined in >>>>>> OIDC." >>>>>> >>>>>> Seems like the perfect mini extension draft for OIDF to do. >>>>>> >>>>>> --Justin >>>>>> >>>>>> /sent from my phone/ >>>>>> >>>>>> >>>>>> On Jul 22, 2014 10:29 AM, Nat Sakimura <sakim...@gmail.com> wrote: >>>>>> > >>>>>> > What about just defining a new grant type in this WG? >>>>>> > >>>>>> > >>>>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.h...@oracle.com>: >>>>>> >> >>>>>> >> That would be nice. However oidc still needs the new grant type in >>>>>> >> order to implement the same flow. >>>>>> >> >>>>>> >> Phil >>>>>> >> >>>>>> >> On Jul 22, 2014, at 11:35, Nat Sakimura <sakim...@gmail.com> wrote: >>>>>> >> >>>>>> >>> +1 to Justin. >>>>>> >>> >>>>>> >>> >>>>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jric...@mitre.org>: >>>>>> >>>> >>>>>> >>>> Errors like these make it clear to me that it would make much more >>>>>> >>>> sense to develop this document in the OpenID Foundation. It should >>>>>> >>>> be something that directly references OpenID Connect Core for all >>>>>> >>>> of these terms instead of redefining them. It's doing >>>>>> >>>> authentication, which is fundamentally what OpenID Connect does on >>>>>> >>>> top of OAuth, and I don't see a good argument for doing this work >>>>>> >>>> in this working group. >>>>>> >>>> >>>>>> >>>> -- Justin >>>>>> >>>> >>>>>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.bro...@gmail.com> >>>>>> >>>> wrote: >>>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones >>>>>> >>>>> <michael.jo...@microsoft.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Thanks for your review, Thomas. The "prompt=consent" definition >>>>>> >>>>>> being missing is an editorial error. It should be: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> consent >>>>>> >>>>>> >>>>>> >>>>>> The Authorization Server SHOULD prompt the End-User for consent >>>>>> >>>>>> before returning information to the Client. If it cannot obtain >>>>>> >>>>>> consent, it MUST return an error, typically consent_required. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I'll plan to add it in the next draft. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> It looks like the consent_required error needs to be defined too, >>>>>> >>>>> and you might have forgotten to also import >>>>>> >>>>> account_selection_required from OpenID Connect. >>>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I agree that there's no difference between a response with >>>>>> >>>>>> multiple "amr" values that includes "mfa" and one that doesn't. >>>>>> >>>>>> Unless a clear use case for why "mfa" is needed can be >>>>>> >>>>>> identified, we can delete it in the next draft. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> Thanks. >>>>>> >>>>> >>>>>> >>>>> How about "pwd" then? I fully understand that I should return >>>>>> >>>>> "pwd" if the user authenticated using a password, but what "the >>>>>> >>>>> service if a client secret is used" means in the definition for >>>>>> >>>>> the "pwd" value? >>>>>> >>>>> >>>>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come >>>>>> >>>>> back ;-) ) >>>>>> >>>>> >>>>>> >>>>> -- >>>>>> >>>>> Thomas Broyer >>>>>> >>>>> /tɔ.ma.bʁwa.je/ >>>>>> >>>>> _______________________________________________ >>>>>> >>>>> OAuth mailing list >>>>>> >>>>> OAuth@ietf.org >>>>>> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> _______________________________________________ >>>>>> >>>> OAuth mailing list >>>>>> >>>> OAuth@ietf.org >>>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> -- >>>>>> >>> Nat Sakimura (=nat) >>>>>> >>> Chairman, OpenID Foundation >>>>>> >>> http://nat.sakimura.org/ >>>>>> >>> @_nat_en >>>>>> >>> >>>>>> >>> _______________________________________________ >>>>>> >>> OAuth mailing list >>>>>> >>> OAuth@ietf.org >>>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Nat Sakimura (=nat) >>>>>> > Chairman, OpenID Foundation >>>>>> > http://nat.sakimura.org/ >>>>>> > @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=nat) >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=nat) >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thomas Broyer >>>>>> /tɔ.ma.bʁwa.je/ >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thomas Broyer >>>>>> /tɔ.ma.bʁwa.je/ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=nat) >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=nat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=nat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
