Again — isn’t this just the client credentials grant but with extra steps?
— Justin > On Mar 1, 2020, at 11:33 AM, Phillip Hunt <[email protected]> wrote: > > Why not just require service accounts to use mutually acceptable http method > of authentication? Eg instead id/password, service acnt client could use > mtls auth or http basic or some other method. > > AFAIK this is already widely done. > > Is there so much interop value that specifying only the weakest form of > authentication is warranted? > > Phil > >> On Mar 1, 2020, at 4:09 AM, Dominick Baier <[email protected]> wrote: >> >> >> 2) write an OAuth 2.1 extension for service account grants. (the grant type >> could continue to be "password", but now clearly in the context of a service >> account in a different document) >> >> IMHO - if such a thing gets defined, it should be a separate document. Keep >> 2.1 as simple as possible. >> >> ——— >> Dominick Baier >> >> On 28. February 2020 at 22:04:10, Dick Hardt ([email protected] >> <mailto:[email protected]>) wrote: >> >>> It looks like there is consensus to remove ROPC for a user -- but that the >>> password grant is not a bad practice for service accounts. That leads to >>> providing clarity on service accounts. >>> >>> 1) add service account grant to the OAuth 2.1 document >>> >>> 2) write an OAuth 2.1 extension for service account grants. (the grant type >>> could continue to be "password", but now clearly in the context of a >>> service account in a different document) >>> >>> With the goal of OAuth 2..1 being a capture of all the best practices, (2) >>> makes more sense as it could discuss all aspects of service accounts >>> including mapping a client to a service account. >>> >>> What do others think? >>> >>> >>> ᐧ >>> >>> On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura <[email protected] >>> <mailto:[email protected]>> wrote: >>> Let us do it then and deprecate ROPC. >>> There definitely are use-cases that need this pattern around me as well, >>> but we are using JWT bearer grant instead. Standardizing the behavior is >>> good. I am fine with new service_account grant type as well, btw. >>> >>> Nat >>> 2020年2月25日 20:41 +0900、Neil Madden <[email protected] >>> <mailto:[email protected]>> のメール: >>>> I’d be open to defining a new service_account grant type and >>>> removing/deprecating the ROPC grant. I’d also be happy if we just said >>>> that service account flows should use the JWT bearer grant, and we >>>> document the best practices around that and encourage client libs to >>>> implement support for it. >>>> >>>> Should there be a dedicated draft for best practices for >>>> service-to-service usage? >>>> >>>> — Neil >>>> >>>>> On 25 Feb 2020, at 00:13, Aaron Parecki <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> I think we might be going about this discussion the wrong way. >>>>> >>>>> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell >>>>> <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> Concur with the sentiment expressed by Neil here. >>>>> >>>>> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> I’m not really sure the WG should be telling people what they “ought to >>>>> be doing” unless we have concrete security or interoperability reasons >>>>> for doing so. >>>>> >>>>> I 100% agree that the job of a standard is not to tell people "what they >>>>> ought to be doing". Instead, a standard is more about documenting the >>>>> current state of the art as deployed in existing implementations. >>>>> >>>>> With that in mind, I think that leaves us with two concrete problems with >>>>> the password grant: >>>>> >>>>> 1) The actual problem with the password grant is end users entering >>>>> passwords in applications, which the group (mostly) agrees on >>>>> 2) People are re-appropriating the password grant for things like service >>>>> accounts or backends that are inflexible, not actually using it for end >>>>> user credentials >>>>> >>>>> So it seems like there's actually something missing from OAuth which is >>>>> leading people to find the password grant and use that because it's the >>>>> only thing that most closely fits their existing model. It seems like >>>>> we'd be better off defining a new extension that captures the use case >>>>> people are actually doing, instead of encouraging the continuing use of >>>>> the password grant for this purpose. >>>>> >>>>> ---- >>>>> Aaron Parecki >>>>> aaronparecki.com <http://aaronparecki.com/> >>>>> @aaronpk >>>>> >>>>> >>>>> >>>>> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell >>>>> <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> Concur with the sentiment expressed by Neil here. >>>>> >>>>> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> I’m not really sure the WG should be telling people what they “ought to >>>>> be doing” unless we have concrete security or interoperability reasons >>>>> for doing so. >>>>> >>>>> I also don’t agree that people doing this are doing anything wrong. I >>>>> don’t always agree with what our customers do, but I’ve learnt over the >>>>> years not to second-guess their reasons for doing it. >>>>> >>>>> Are Google wrong for using the JWT bearer grant (not client credentials) >>>>> and service accounts? They even go so far as to say “scopes are not a >>>>> security mechanism” [1] and tell people to use service account roles >>>>> instead. (Precisely because they also support non-OAuth auth methods, >>>>> which bypass any scopes). >>>>> >>>>> Are we really going to tell them to rewrite it all to use the client >>>>> credentials grant? >>>>> >>>>> [1]: >>>>> https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam >>>>> >>>>> <https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam> >>>>> >>>>>> On 21 Feb 2020, at 21:04, Justin Richer <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> +1. I’ve seen this anti-pattern deployed all over the place, and it’s >>>>>> time to get rid of it and send people toward what they really ought to >>>>>> be doing. >>>>>> >>>>>> Another thing I’ve seen is using different service accounts to get >>>>>> different sets of access for one client — if you’re doing that, you’ve >>>>>> got a client pretending to do two different things, or your APIs should >>>>>> be using scopes to differentiate access instead of client/user identity. >>>>>> >>>>>> — Justin >>>>>> >>>>>>> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle >>>>>>> <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> The client IDs can still be opaque identifiers provided by the AS, they >>>>>>> just happen to be associated with specific service accounts. Or they >>>>>>> could be the opaque IDs that the AS already issued for the service >>>>>>> account. Either way, the AS could issue a token with the appropriate >>>>>>> subject and other claims for the service account. >>>>>>> >>>>>>> If your client identity is bound to a specific service account identity >>>>>>> (i.e.., the resource owner), then ROPC reduces down to Client >>>>>>> Credentials. What's the point in passing two identifiers and two >>>>>>> credentials for the same identity? >>>>>>> >>>>>>> – >>>>>>> Annabelle Backman (she/her) >>>>>>> AWS Identity >>>>>>> https://aws.amazon.com/identity/ <https://aws.amazon.com/identity/> >>>>>>> >>>>>>> >>>>>>> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" >>>>>>> <[email protected] <mailto:[email protected]> on behalf of >>>>>>> [email protected] <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> Sorry, I missed that message. >>>>>>> >>>>>>> While this may be a solution in specific circumstances, I don’t think >>>>>>> it’s a general solution. e.g. an AS may not allow manually choosing the >>>>>>> client_id to avoid things like >>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 >>>>>>> >>>>>>> <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4..13> >>>>>>> or may return different introspection results for client credentials >>>>>>> tokens (e.g.. with no “sub”) and so on. In practice, this adds even >>>>>>> more steps for somebody to migrate from existing ROPC usage. >>>>>>> >>>>>>> This is asking people to make fundamental changes to their identity >>>>>>> architecture rather than simply switching to a new grant type.. >>>>>>> >>>>>>> — Neil >>>>>>> >>>>>>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <[email protected] >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> I see - we have gone full cycle :-) >>>>>>>> >>>>>>>> Annabelle’s proposal would solve that. Relate a client id to a service >>>>>>>> account and obtain the token data from there. >>>>>>>> >>>>>>>>> On 21. Feb 2020, at 15:31, Neil Madden <[email protected] >>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>> >>>>>>>>> Yes, that is great. But mTLS doesn’t support service accounts (!= >>>>>>>>> clients). Maybe it should? Should there be a mTLS *grant type*? >>>>>>>>> >>>>>>>>> — Neil >>>>>>>>> >>>>>>>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt >>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>> >>>>>>>>>> Have you ever tried the client credentials grant with mTLS? After >>>>>>>>>> reading your description it seems to be simpler than JWT Bearer.. >>>>>>>>>> >>>>>>>>>> * work out if the AS even supports mTLS >>>>>>>>>> * work out how to configure the AS to trust my cert(s) >>>>>>>>>> * Create key pair and cert using openssl >>>>>>>>>> * Register your (self-signed) cert along with your client_id >>>>>>>>>> * Configure the HTTP client to use your key pair for TLS Client >>>>>>>>>> Authentication >>>>>>>>>> >>>>>>>>>> Works very well for us. >>>>>>>>>> >>>>>>>>>>> On 21. Feb 2020, at 15:12, Neil Madden <[email protected] >>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>> >>>>>>>>>>> No failures, but it is a much more complex grant type to set up, >>>>>>>>>>> when you consider everything you have to do: >>>>>>>>>>> >>>>>>>>>>> * work out if the AS even supports JWT bearer and how to turn it on >>>>>>>>>>> * work out how to configure the AS to trust my public key(s) >>>>>>>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>>>>>>>>>> * determine the correct settings for issuer, audience, subject, >>>>>>>>>>> etc. Does the AS impose non-standard requirements? e.g. RFC 7523 >>>>>>>>>>> says that the JWT MUST contain a “sub” claim, but Google only >>>>>>>>>>> allows this to be present if your client is doing impersonation of >>>>>>>>>>> an end-user (which requires additional permissions). >>>>>>>>>>> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth >>>>>>>>>>> ones might not) If I do, can I reuse the JWT or must it be freshly >>>>>>>>>>> signed for every call? >>>>>>>>>>> * locate and evaluate a JWT library for my language of choice. >>>>>>>>>>> Monitor that new dependency for security advisories. >>>>>>>>>>> * choose a suitable signature algorithm (‘ere be dragons) >>>>>>>>>>> * figure out how to distribute the private key to my service >>>>>>>>>>> >>>>>>>>>>> Compared to “create a service account and POST the username and >>>>>>>>>>> password to the token endpoint” it adds a little friction. (It also >>>>>>>>>>> adds a lot of advantages, but it is undeniably more complex). >>>>>>>>>>> >>>>>>>>>>> — Neil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast >>>>>>>>>>>> <[email protected] >>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I have a feeling that if we had more concise JWT libraries and >>>>>>>>>>>> command line tools, where using the JWT Bearer grant became a >>>>>>>>>>>> one-liner again then we wouldn’t be having this conversation. So >>>>>>>>>>>> perhaps removing it is an incentive to make that happen. >>>>>>>>>>>> >>>>>>>>>>>> Neil could you elaborate more on this please. What failures are >>>>>>>>>>>> you currently experiencing/seeing with the JWT Bearer grant? >>>>>>>>>>>> >>>>>>>>>>>> Matt >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden >>>>>>>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> I have a feeling that if we had more concise JWT libraries and >>>>>>>>>>>> command line tools, where using the JWT Bearer grant became a >>>>>>>>>>>> one-liner again then we wouldn’t be having this conversation. So >>>>>>>>>>>> perhaps removing it is an incentive to make that happen. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt <[email protected] >>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Neil: are you advocating that password grant be preserved in 2.1? >>>>>>>>>>>>> Or do you think that service account developers know enough about >>>>>>>>>>>>> what they are doing to follow what is in 6749? >>>>>>>>>>>>> ᐧ >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden >>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>> OAuth2 clients are often private to the AS - they live in a >>>>>>>>>>>>> database that only the AS can access, have attributes specific to >>>>>>>>>>>>> their use in OAuth2, and so on. Many existing systems have access >>>>>>>>>>>>> controls based on users, roles, permissions and so on and expect >>>>>>>>>>>>> all users accessing the system to exist in some user repository, >>>>>>>>>>>>> e.g. LDAP, where they can be looked up and appropriate >>>>>>>>>>>>> permissions determined. A service account can be created inside >>>>>>>>>>>>> such a system as if it was a regular user, managed through the >>>>>>>>>>>>> normal account provisioning tools, assigned permissions, roles, >>>>>>>>>>>>> etc. >>>>>>>>>>>>> >>>>>>>>>>>>> Another reason is that sometimes OAuth is just one authentication >>>>>>>>>>>>> option out of many, and so permissions assigned to service >>>>>>>>>>>>> accounts are preferred over scopes because they are consistently >>>>>>>>>>>>> applied no matter how a request is authenticated. This is often >>>>>>>>>>>>> the case when OAuth has been retrofitted to an existing system >>>>>>>>>>>>> and they need to preserve compatibility with already deployed >>>>>>>>>>>>> clients. >>>>>>>>>>>>> >>>>>>>>>>>>> See e.g. Google cloud platform (GCP): >>>>>>>>>>>>> https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>>>>>>>>>>>> >>>>>>>>>>>>> <https://developers.google.com/identity/protocols/OAuth2ServiceAccount> >>>>>>>>>>>>> They use the JWT bearer grant type for service account >>>>>>>>>>>>> authentication and assign permissions to those service accounts >>>>>>>>>>>>> and typically have very broad scopes. For service-to-service API >>>>>>>>>>>>> calls you typically get an access token with a single scope that >>>>>>>>>>>>> is effectively “all of GCP” and everything is managed at the >>>>>>>>>>>>> level of permissions on the RO service account itself. They only >>>>>>>>>>>>> break down fine-grained scopes when you are dealing with user >>>>>>>>>>>>> data and will be getting an access token approved by a real user >>>>>>>>>>>>> (through a normal auth code flow). >>>>>>>>>>>>> >>>>>>>>>>>>> — Neil >>>>>>>>>>>>> >>>>>>>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt >>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can you explain more in detail why the client credentials grant >>>>>>>>>>>>>> type isn’t applicable for the kind of use cases you mentioned? >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden >>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I very much agree with this with regards to real users. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The one legitimate use-case for ROPC I’ve seen is for service >>>>>>>>>>>>>>> accounts - where you essentially want something like >>>>>>>>>>>>>>> client_credentials but for whatever reason you need the RO to >>>>>>>>>>>>>>> be a service user rather than an OAuth2 client (typically so >>>>>>>>>>>>>>> that some lower layer of the system can still perform its >>>>>>>>>>>>>>> required permission checks). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There are better grant types for this - e.g. JWT bearer - but >>>>>>>>>>>>>>> they are a bit harder to implement. Having recently converted >>>>>>>>>>>>>>> some code from ROPC to JWT bearer for exactly this use-case, it >>>>>>>>>>>>>>> went from a couple of lines of code to two screens of code. For >>>>>>>>>>>>>>> service to service API calls within a datacenter I’m not >>>>>>>>>>>>>>> convinced this resulted in a material increase in security for >>>>>>>>>>>>>>> the added complexity. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> — Neil >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt >>>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would also seriously look at the original motivation behind >>>>>>>>>>>>>>>> ROPC: I know it has been deployed and is used in quite a lot >>>>>>>>>>>>>>>> of places but I have never actually come across a use case >>>>>>>>>>>>>>>> where it is used for migration purposes and the migration is >>>>>>>>>>>>>>>> actually executed (I know that is statistically not a very >>>>>>>>>>>>>>>> strong argument but I challenge others to come up with one...) >>>>>>>>>>>>>>>> In reality it turned out just to be a one off that people used >>>>>>>>>>>>>>>> as an easy way out to stick to an anti-pattern and still claim >>>>>>>>>>>>>>>> to do OAuth 2.0. It is plain wrong, it is not OAuth and we >>>>>>>>>>>>>>>> need to get rid of it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki >>>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting >>>>>>>>>>>>>>>> as a grace period since it currently says the password grant >>>>>>>>>>>>>>>> MUST NOT be used, so in the OAuth 2.0 world that's already a >>>>>>>>>>>>>>>> pretty strong signal.. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Aaron >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer <[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 >>>>>>>>>>>>>>>> can still do OAuth 2.0. People using OAuth 2..1 will do OAuth >>>>>>>>>>>>>>>> 2.1. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> — Justin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin >>>>>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are still >>>>>>>>>>>>>>>>> sites using this and a grace period should be provided before >>>>>>>>>>>>>>>>> a MUST is pushed out as there are valid use cases out there >>>>>>>>>>>>>>>>> still. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> From: OAuth <[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>> On Behalf Of Dick Hardt >>>>>>>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>>>>>>>>>>> To: [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password >>>>>>>>>>>>>>>>> grant >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hey List >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for the >>>>>>>>>>>>>>>>> doc that Aaron, Torsten, and I are working on) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In the security topics doc >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2..4> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The password grant MUST not be used. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Some background for those interested. I added this grant into >>>>>>>>>>>>>>>>> OAuth 2.0 to allow applications that had been provided >>>>>>>>>>>>>>>>> password to migrate. Even with the caveats in OAuth 2.0, >>>>>>>>>>>>>>>>> implementors decide they want to prompt the user to enter >>>>>>>>>>>>>>>>> their credentials, the anti-pattern OAuth was created to >>>>>>>>>>>>>>>>> eliminate. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Does anyone have concerns with dropping the password grant >>>>>>>>>>>>>>>>> from the OAuth 2....1 document so that developers don't use >>>>>>>>>>>>>>>>> it? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Dick >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> ---- >>>>>>>>>>>>>>>> Aaron Parecki >>>>>>>>>>>>>>>> aaronparecki.com <http://aaronparecki.com/> >>>>>>>>>>>>>>>> @aaronpk >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>> https://www.ietf. >>>>>>>>>>>>>>> <https://www.ietf./>.org/mailman/listinfo/oauth >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>> >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). Any >>>>> review, use, distribution or disclosure by others is strictly >>>>> prohibited.. If you have received this communication in error, please >>>>> notify the sender immediately by e-mail and delete the message and any >>>>> file attachments from your computer. Thank >>>>> you._______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf..org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
