Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
Apologies if I'm being dim (it wouldn't be the first time!) but how, in this scenario, do we identify the browser client and authenticate it to the backend, to associate it with the correct token(s)? Cheers (and really interesting discussion so far) Rob On Sun, 2 Dec 2018 at 07:31, Torsten Lodderstedt wrote: > the UI is rendered in the frontend, UI control flow is in the frontend. > just a different cut through the web app’s layering > > All Angular apps I have seen so far work that way. And it makes a lot of > sense to me. The backend can aggregate and optimize access to the > underlying services without the need to fully expose them. > > Am 02.12.2018 um 00:44 schrieb John Bradley : > > How is that different from a regular server client with a web interface if > the backed is doing the API calls to the RS? > > > On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: > > I forgot to mention another (architectural) option: split an application > into frontend provided by JS in the browser and a backend, which takes care > of the business logic and handles tokens and API access. Replay detection > at the interface between SPA and backend can utilize standard web > techniques (see OWASP). The backend in turn can use mTLS for sender > constraining. > > Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt < > tors...@lodderstedt.net>: > > IMHO the best mechanism at hand currently to cope with token > leakage/replay in SPAs is to use refresh tokens (rotating w/ replay > detection) and issue short living and privilege restricted access tokens. > > Sender constrained access tokens in SPAs need adoption of token binding or > alternative mechanism. mtls could potentially work in deployments with > automated cert rollout but browser UX and interplay with fetch needs some > work. We potentially must consider to warm up application level PoP > mechanisms in conjunction with web crypto. Another path to be evaluated > could be web auth. > > Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig < > hannes.tschofe...@arm.com>: > > I share the concern Brian has, which is also the conclusion I came up with > in my other email sent a few minutes ago. > > > > *From:* OAuth *On Behalf Of *Brian Campbell > *Sent:* Friday, November 30, 2018 11:43 PM > *To:* Torsten Lodderstedt > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 > > > > > > On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > > > Am 15.11.2018 um 23:01 schrieb Brock Allen : > > > > So you mean at the resource server ensuring the token was really issued > to the client? Isn't that an inherent limitation of all bearer tokens > (modulo HTTP token binding, which is still some time off)? > > Sure. That’s why the Security BCP recommends use of TLS-based methods for > sender constraining access tokens ( > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2). > Token Binding for OAuth ( > https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08 > <https://tools..ietf.org/html/draft-ietf-oauth-token-binding-08>) as well > as Mutual TLS for OAuth ( > https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options > available. > > > > Unfortunately even when using the token endpoint, for SPA / in-browser > client applications, the potential mechanisms for sender/key-constraining > access tokens don't work very well or maybe don't work at all. So I don't > know that the recommendation is very realistic. > > > > > *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.* > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ___ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > ___ > OAuth mailing list > OAuth@ietf.org > ht
Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
ts.pptx >>>>> >>>>> <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx> >>>>>) - got early feedback from Filip Skokan on it. Thx Filip! >>>>>- The presentation was followed up by 1.5 hours of unconference >>>>>discussion, which was incredibly valuable to get tight-loop feedback >>>>> and >>>>>incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, >>>>>Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all >>>>>there and contributed generously to the discussion. Thank you!!! >>>>>Note: if you were at OSW2019, participated in the discussion and >>>>>didn't get credited in the draft, my apologies: please send me a note >>>>> and >>>>>I'll make things right at the next update. >>>>>- On my flight back I did my best to incorporate all the ideas and >>>>>feedback in a draft, which will be discussed at IETF104 tomorrow. >>>>> Rifaat, >>>>>Hannes and above all Brian were all super helpful in negotiating the >>>>>mysterious syntax of the RFC format and submission process. >>>>> >>>>> I was blown away by the availability, involvement and willingness to >>>>> invest time to get things right that everyone demonstrated in the process. >>>>> This is an amazing community. >>>>> V. >>>>> ___ >>>>> 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 >>>>> >>>> >>>> >>>> -- >>>> hans.zandb...@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>>> >>> >>> -- >>> hans.zandb...@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >> ___ >> 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 > -- Rob Otto EMEA Field CTO - Ping Identity +44 777 135 6092 -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] MTLS and Native apps Best practices
Are you hoping to use the key to authenticate the user, or the OAuth client? If it's the latter, then you don't need to use MTLS to the authorisation endpoint. If it's the former, I'd argue that you would certainly need to include your public key in an X509 cert and *somehow* make it available to the system browser. On Fri, 3 May 2019 at 08:07, Phil Hunt wrote: > Yes. I was more wondering if the app can invoke the system embedded view > using its own key pair to ensure protected authen. > > Eg. If the authorization endpoint is set to require mutual tls, can the > system view use the app’s keys since the app is invoking it? > > Or, would there have to be a user x..509 cert embedded in the browser > store? > > I agree browser based apps is another matter. > > Phil > > On May 2, 2019, at 11:27 PM, Torsten Lodderstedt > wrote: > > Hi Phil, > > since mTLS is used at the tokens endpoint, native apps can definitely use > their own key pair. I would asunder such an app to act as public client, > but mTLS would allow such an app to bind its key pair with the token > request to the issued tokens. > > Apps running in the browser is a separate topic. There are potential > issues with using the certs in the browser. That’s why work towards an > application level PoP mechanism has been started - DPoP. > > best regards, > Torsten. > > Am 02.05.2019 um 20:41 schrieb Phil Hunt : > > I was wondering if anyone had any recommended MTLS best practices for > mobile apps and native browsers. > > Considering Section 6 of RFC8252… > >After constructing the authorization request URI, the app uses >platform-specific APIs to open the URI in an external user-agent. >Typically, the external user-agent used is the default browser, that >is, the application configured for handling "http" and "https" scheme >URIs on the system; however, different browser selection criteria and >other categories of external user-agents MAY be used. > > > What choices do developers have to ensure the authorization (and > subsequent user authentication) occur over MTLS? Can the app provide its > own key for MTLS or can it ask that an embedded X.509 cert be used > (assuming one is available)? > > Are there any platform issues or best practices? > > Phil Hunt | Cloud Security and Identity Architect > Oracle Corporation, Oracle Cloud Infrastructure > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > > ___ > 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 > -- <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Rob Otto EMEA Field CTO/Solutions Architect robo...@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image: LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter logo] <https://twitter.com/pingidentity> [image: facebook logo] <https://www.facebook.com/pingidentitypage> [image: youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo] <https://plus.google.com/u/0/114266977739397708540> [image: Blog logo] <https://www.pingidentity.com/en/blog.html> <https://www.pingidentity.com/content/ping/en/lp/d/p14e-trial.html> <https://www.pingidentity.com/en/lp/d/p14e-trial.html?utm_source=Email&utm_medium=p14e-trial-sso-mfa-emailsig&utm_campaign=p14e-trial-sso-mfa-emailsig> <https://www.pingidentity.com/en/lp/d/p14e-trial.html?utm_source=Email&utm_medium=p14e-trial-sso-mfa-emailsig&utm_campaign=p14e-trial-sso-mfa-emailsig> <https://developer.pingidentity.com/en/signup.html> <https://developer.pingidentity.com/en/signup.html> <https://developer.pingidentity.com/en/signup.html> <https://developer.pingidentity.com/en/signup.html?utm_source=email&utm_medium=P14C-Trial-Email&utm_campaign=P14C-Trial-Email&utm_content=link> <https://developer.pingidentity.com/en/signup.html?utm_source=email&utm_medium=P14C-Trial-Email&utm_campaign=P14C-Trial-Email&utm_content=link> -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Question regarding RFC 8628
Salut Hervé I wonder if you have looked at all at the OpenID Connect Client-Initiated BackChannel Authentication (CIBA) flow for this use case? Certainly the feeling amongst the Open Banking community here in the UK is that it might be a better fit for decoupled authentication than the Device Authorisation Grant. There is even a FAPi (Financial-Grade API) profile of CIBA that is making its way through the standardisation process - and even has a working conformance testing suite. The other option, that could make life easier when it comes to the final step you mention (switching back to the TPP app from the Bank app) is to use an app-to-app redirect model under OIDC. Again this is a popular model for same-device scenarios that's been implemented by many banks here in the UK. If you'd like more information on either of these approaches, I'm happy to share. Best regards Rob On Mon, 18 Nov 2019 at 08:24, Robache Hervé wrote: > Dear all > > > > We are considering using RFC8628 for a specific use case that is related > to the version 2 of Payment Service Directive in Europe (PSD2). > > > > The purpose of the work is to provide a decoupled authentication flow for > a payment Service User (PSU) aiming to grant access to a Third Party > Provider (TPP) for his/her data hosted by a Bank. > > The sequence should be as followed: > > - Nominal flow (as specified by the RFC) > > o The TPP asks the PSU about the Bank identity > > o The TPP posts a Device Access Token Request to the Bank > > o The Bank sends back a Device Access Token response to the TPP > > o The TPP starts to poll the bank for gaining the access token > > - Derived flow > > o The “verification_uri_complete” will not be displayed to the PSU but > used as an [app link]/[universal link] on a smartphone in order to launch > the bank’s app. > > o The bank’s app authenticates the PSU and asks for consent confirmation > > - Back to the nominal flow > > o The TPP gets its access token > > > > Two questions have raised during the work > > - As RFC8628 is supposed to work on separate devices, can the > usage be extrapolated to separate apps on the same device (i.e. the PSU’s > smartphone)? > > - One issue of the derived flow is that, after authentication, > the PSU is still facing the bank’s app > > o We would like to go back to the TPP’s app as fluently as possible. > The use of another [app link]/[universal link]could do the job is provided > by the TPP. We consider adding this uri as an additional parameter to the > “verification_uri_complete”. > > o Is this compliant with RFC8628? > > > > Thanks in advance for your answers. > > > > Hervé Robache > > > Ce message et toutes les pièces jointes sont établis à l'intention > exclusive de ses destinataires et sont confidentiels. > Si vous recevez ce message par erreur ou s'il ne vous est pas destiné, > merci de le détruire ainsi que toute copie de votre système et d'en avertir > immédiatement l'expéditeur. > Toute lecture non autorisée, toute utilisation de ce message qui n'est pas > conforme à sa destination, toute diffusion ou toute publication, totale ou > partielle, est interdite. > L'Internet ne permettant pas d'assurer l'intégrité de ce message > électronique susceptible d'altération, STET décline toute responsabilité au > titre de ce message dans l'hypothèse où il aurait été modifié, déformé ou > falsifié. > N'imprimez ce message que si nécessaire, pensez à l'environnement. > > This message and any attachments is intended solely for the intended > addressees and is confidential. > If you receive this message in error, or are not the intended > recipient(s), please delete it and any copies from your systems and > immediately notify the sender. > Any unauthorized view, use that does not comply with its purpose, > dissemination or disclosure, either whole or partial, is prohibited. > Since the internet cannot guarantee the integrity of this message which > may not be reliable, STET shall not be liable for the message if modified, > changed or falsified. > Do not print this message unless it is necessary, please consider the > environment. > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Rob Otto EMEA Field CTO/Solutions Architect roberto...@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_
Re: [OAUTH-WG] review draft-ietf-oauth-security-topics-13 [3/3]
" don't use the Implicit or Resource Owner Password Credentials grant types" I cannot overstate how strongly I would support this recommendation in particular! Best regards Rob On Tue, 19 Nov 2019 at 10:07, Hans Zandbelt wrote: > How about: > > - don't use the Implicit or Resource Owner Password Credentials grant > types > - perform exact matching of redirect URIs and make then Client/AS specific > - use PKCE > > Hans. > > On Tue, Nov 19, 2019 at 5:58 PM Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> >> >> > On 19. Nov 2019, at 17:10, Hans Zandbelt >> wrote: >> > >> > >> > >> > On Tue, Nov 19, 2019 at 10:38 AM Torsten Lodderstedt < >> tors...@lodderstedt.net> wrote: >> > Hi Hans, >> > >> > > On 18. Nov 2019, at 04:11, Hans Zandbelt >> wrote: >> > > >> > > Hi, >> > > >> > > Please find my feedback from page 21 onwards below. >> > > >> > > Hans. >> > > >> > > Overall I would argue there's room for a very concise guidance >> section that says: do this, don't do that, without explanation, just as a >> reference for developers; the current text provides in depth analysis but >> that is perhaps not suitable for developers who just want to know what to >> do (or not to do) and don't really care about the background/reasoning >> > >> > While section 4 gives the raw security threat analysis, we tried to >> summarise the actionable guidance in section 3. What do you miss there? >> > >> > I'd rather see it even shorter and more concise, but I guess you're >> right, it is there >> >> Do you want to suggest some text? >> >> > >> > > >> > > P21 >> > > first bullet >> > > "the client has bound this data to this particular instance." -> >> particular instance of what? >> > >> > This bullet refers to the note above. >> > >> > "Note: this check could also detect attempts to inject a code which >> >had been obtained from another instance of the same client on another >> >device, if certain conditions are fulfilled:" >> > >> > ok, I see >> > >> > > >> > > 3rd paragraph: >> > > "call to the tokens endpoint." -> "call to the token endpoint." >> > >> > Fixed >> > >> > > >> > > last paragraph could forward point to the next section by adding >> something like >> > > "using one of the mechanisms described in the next section." >> > >> > Incorporated >> > >> > > >> > > P22 >> > > 3rd paragraph: >> > > is the token binding guidance still accurate? it seems to be >> overestimating the adoption >> > >> > You mean this statement? >> > >> > "Token binding is >> > promising as a secure and convenient mechanism (due to its browser >> > integration). As a challenge, it requires broad browser support >> > and use with native apps is still under discussion.” >> > >> > yeah, but after re-reading I guess this actually spells out the >> adoption conditions, so it is fine >> > >> > Hans. >> > >> > >> > Thanks, >> > Torsten. >> > >> > > >> > > -- >> > > hans.zandb...@zmartzone.eu >> > > ZmartZone IAM - www.zmartzone.eu >> > > ___ >> > > OAuth mailing list >> > > OAuth@ietf.org >> > > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > -- >> > hans.zandb...@zmartzone.eu >> > ZmartZone IAM - www.zmartzone.eu >> >> > > -- > hans.zandb...@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Rob Otto EMEA Field CTO/Solutions Architect roberto...@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image: LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter logo] <https://twitter.com/pingidentity> [image: facebook logo] <https://www.facebook.com/pingidentitypage> [image: youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo] <https://plus.google.com/u/0/114266977739397708540> [image: Blog logo] <https://www.pingidentity.com/en/blog.html> <https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ> <https://www.pingidentity.com/en/events/d/identify-2019.html> -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt
Hi everyone I'd agree with this. I'm looking at DPOP as an alternative and ultimately simpler way to accomplish what we can already do with MTLS-bound Access Tokens, for use cases such as the ones we address in Open Banking; these are API transactions that demand a high level of assurance and as such we absolutely must have a mechanism to constrain those tokens to the intended bearer. Requiring MTLS across the ecosystem, however, adds significant overhead in terms of infrastructural complexity and is always going to limit the extent to which such a model can scale. DPOP, to me, appears to be a rather more elegant way of solving the same problem, with the benefit of significantly reducing the complexity of (and dependency on) the transport layer. I would not argue, however, that it is meant to be a solution intended for ubiquitous adoption across all OAuth-protected API traffic. Clients still need to manage private keys under this model and my experience is that there is typically a steep learning curve for developers to negotiate any time you introduce a requirement to hold and use keys within an application. I guess I'm with Justin - let's look at DPOP as an alternative to MTLS-bound tokens for high-assurance use cases, at least initially, without trying to make it solve every problem. Best regards Rob On Fri, 22 Nov 2019 at 07:24, Justin Richer wrote: > I’m going to +1 Dick and Annabelle’s question about the scope here. That > was the one major thing that struck me during the DPoP discussions in > Singapore yesterday: we don’t seem to agree on what DPoP is for. Some > (including the authors, it seems) see it as a quick point-solution to a > specific use case. Others see it as a general PoP mechanism. > > If it’s the former, then it should be explicitly tied to one specific set > of things. If it’s the latter, then it needs to be expanded. > > I’ll repeat what I said at the mic line: My take is that we should > explicitly narrow down DPoP so that it does exactly one thing and solves > one narrow use case. And for a general solution? Let’s move that discussion > into the next major revision of the protocol where we’ll have a bit more > running room to figure things out. > > — Justin > > On Nov 22, 2019, at 3:13 PM, Dick Hardt wrote: > > > > On Fri, Nov 22, 2019 at 3:08 PM Neil Madden > wrote: > >> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle >> wrote: >> >> There are key distribution challenges with that if you are doing >> validation at the RS, but validation at the RS using either approach means >> you’ve lost protection against replay by the RS. This brings us back to a >> core question: what threats are in scope for DPoP, and in what contexts? >> >> >> Agreed, but validation at the RS is premature optimisation in many cases.. >> And if you do need protection against that the client can even append a >> confirmation key as a caveat and retrospectively upgrade a bearer token to >> a pop token. They can even do transfer of ownership by creating copies of >> the original token bound to other certificates/public keys. >> > > While validation at the RS may be an optimization in many cases, it is > still a requirement for deployments. > > I echo Annabelle's last question: what threats are in scope (and out of > scope) for DPoP? > > > ___ > 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 > -- <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Rob Otto EMEA Field CTO/Solutions Architect roberto...@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image: LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter logo] <https://twitter.com/pingidentity> [image: facebook logo] <https://www.facebook.com/pingidentitypage> [image: youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo] <https://plus.google.com/u/0/114266977739397708540> [image: Blog logo] <https://www.pingidentity.com/en/blog.html> <https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ> <https://www.pingidentity.com/en/events/d/identify-2019.html> -- _CONFIDENTIALITY NOTICE: This email may contain confident
Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt
Hi Torsten - thanks for the reply. Responses in line. Grüsse Rob On Fri, 22 Nov 2019 at 07:59, Torsten Lodderstedt wrote: > Hi Rob, > > > On 22. Nov 2019, at 15:52, Rob Otto 40pingidentity@dmarc.ietf.org> wrote: > > > > Hi everyone > > > > I'd agree with this. I'm looking at DPOP as an alternative and > ultimately simpler way to accomplish what we can already do with MTLS-bound > Access Tokens, for use cases such as the ones we address in Open Banking; > these are API transactions that demand a high level of assurance and as > such we absolutely must have a mechanism to constrain those tokens to the > intended bearer. Requiring MTLS across the ecosystem, however, adds > significant overhead in terms of infrastructural complexity and is always > going to limit the extent to which such a model can scale. > > I would like to unterstand why mTLS adds “significant overhead in terms of > infrastructural complexity”. Can you please dig into details? > I guess it's mostly that every RS-endpoint (or what sits in front of it) has to have a mechanism for accepting/terminating mTLS, managing roots of trust, validating/OCSP, etc and then passing the certificates downstream as headers. None of it is necessarily difficult or impossible to do in isolation, but I meet many many people every week who simply don't know how to do any of this stuff. And these are typically "network people", for want of a better word. There are quite a few SaaS API management and edge solutions out there that don't even support mTLS at all. You also have the difficulty in handling a combination of MTLS and non-MTLS traffic to the same endpoints. Again, it's possible to do, but far from straightforward. > > Our experience so far: It can be a headache to set up in a microservice > architecture with TLS terminating proxies but once it runs it’s ok. On the > other side, it’s easy to use for client developers and it combines client > authentication and sender constraining nicely. > I do think its an elegant solution, don't get me wrong. It's just that there are plenty of moving parts that you need to get right and that can be a challenge, particularly in large, complex environments. > > > > > DPOP, to me, appears to be a rather more elegant way of solving the same > problem, with the benefit of significantly reducing the complexity of (and > dependency on) the transport layer. I would not argue, however, that it is > meant to be a solution intended for ubiquitous adoption across all > OAuth-protected API traffic. Clients still need to manage private keys > under this model and my experience is that there is typically a steep > learning curve for developers to negotiate any time you introduce a > requirement to hold and use keys within an application. > > My experience is most developer don’t even get the URL right (in the > signature and the value used on the receiving end). So the total cost of > ownership is increased by numerous support inquiries. > I'll not comment, at the risk of offending developers :) > > best regards, > Torsten. > > > > > I guess I'm with Justin - let's look at DPOP as an alternative to > MTLS-bound tokens for high-assurance use cases, at least initially, without > trying to make it solve every problem. > > > > Best regards > > Rob > > > > > > On Fri, 22 Nov 2019 at 07:24, Justin Richer wrote: > > I’m going to +1 Dick and Annabelle’s question about the scope here. That > was the one major thing that struck me during the DPoP discussions in > Singapore yesterday: we don’t seem to agree on what DPoP is for. Some > (including the authors, it seems) see it as a quick point-solution to a > specific use case. Others see it as a general PoP mechanism. > > > > If it’s the former, then it should be explicitly tied to one specific > set of things. If it’s the latter, then it needs to be expanded. > > > > I’ll repeat what I said at the mic line: My take is that we should > explicitly narrow down DPoP so that it does exactly one thing and solves > one narrow use case. And for a general solution? Let’s move that discussion > into the next major revision of the protocol where we’ll have a bit more > running room to figure things out.. > > > > — Justin > > > >> On Nov 22, 2019, at 3:13 PM, Dick Hardt wrote: > >> > >> > >> > >> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden > wrote: > >> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle < > richa...@amazon.com> wrote: > >>> There are key distribution challenges with that if you are doing > validation at the RS, but validation at the RS using eit
Re: [OAUTH-WG] Meeting Minutes
I’d support adoption of both PAR and RAR. On Mon, 16 Dec 2019 at 21:57, Richard Backman, Annabelle wrote: > +1 for a call for adoption on PAR. > > > > I’d also like to see one for RAR; while there are questions that need to > be resolved, there seems to be strong interest in this work and adoption > means we can have those discussions within the WG where they belong. > > > > – > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Justin Richer < > jric...@mit.edu> > *Date: *Monday, December 16, 2019 at 12:36 PM > *To: *Brian Campbell > *Cc: *"oauth@ietf.org" > *Subject: *Re: [OAUTH-WG] Meeting Minutes > > > > +1 to this. My take away was that PAR was pretty clear for adoption right > now, RAR had interest but more question/debate. > > > > FWIW I’m in favor of both of them. > > > > — Justin > > > > On Dec 16, 2019, at 11:26 AM, Brian Campbell < > bcampbell=40pingidentity@dmarc.ietf.org> wrote: > > > > With respect to the Pushed Authorization Requests (PAR) draft the minutes > do capture an individual comment that it's a "no brainer to adopt this > work" but as I recall there was also a hum to gauge the room's interest in > adoption, which was largely in favor of such. Of course, one hum in > Singapore isn't the final word but, following from that, I was > hoping/expecting to see a call for adoption go out to the mailing list? > > > > On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig < > hannes.tschofe...@arm.com> wrote: > > Here are the meeting minutes from the Singapore IETF meeting: > > https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 > > > > Tony was our scribe. Thanks! > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ___ > OAuth mailing list > OAuth@ietf.org > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Rob Otto EMEA Field CTO - Ping Identity +44 777 135 6092 -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
I support adoption On Mon, 6 Jan 2020 at 22:22, Jim Willeke wrote: > I support adoption. > -- > -jim > Jim Willeke > > > On Mon, Jan 6, 2020 at 3:36 PM Dick Hardt wrote: > >> I support adoption >> ᐧ >> >> On Mon, Jan 6, 2020 at 12:32 PM Richard Backman, Annabelle > 40amazon@dmarc.ietf.org> wrote: >> >>> I support adoption. >>> >>> >>> >>> – >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From: *OAuth on behalf of John Bradley < >>> ve7...@ve7jtb.com> >>> *Date: *Monday, January 6, 2020 at 12:05 PM >>> *To: *"oauth@ietf.org" >>> *Subject: *Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich >>> Authorization Requests >>> >>> >>> >>> I support adoption >>> >>> On 1/6/2020 4:37 PM, Rifaat Shekh-Yusef wrote: >>> >>> All, >>> >>> >>> >>> This is a call for adoption for the *OAuth 2.0 Rich Authorization >>> Requests* document. >>> >>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ >>> >>> >>> >>> Please, let us know if you support or object to the adoption of this >>> document as a working group document by Jan 20th. >>> >>> >>> >>> Regards, >>> >>> Rifaat & Hannes >>> >>> >>> >>> >>> >>> _______ >>> >>> 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 >> > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Rob Otto EMEA Field CTO - Ping Identity +44 777 135 6092 -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for Adoption: DPoP
I support adoption Thank you Rob Otto On Tue, 17 Mar 2020 at 12:21, Rifaat Shekh-Yusef wrote: > All, > > As per the conclusion of the PoP interim meeting, this is a call for > adoption for the *OAuth 2.0 Demonstration of Proof-of-Possession at the > Application Layer (DPoP)* document: > https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/ > > Please, let us know if you support or object to the adoption of this > document as a working group document by March 31st. > > Regards, > Rifaat & Hannes > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Rob Otto EMEA Field CTO/Solutions Architect roberto...@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image: LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter logo] <https://twitter.com/pingidentity> [image: facebook logo] <https://www.facebook.com/pingidentitypage> [image: youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image: Blog logo] <https://www.pingidentity.com/en/blog.html> <https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ> <https://www.pingidentity.com/en/events/d/identify-2019.html> <https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf> <https://www.pingidentity.com/en/events/e/rsa.html> <https://www.pingidentity.com/en/events/e/rsa.html> <https://developer.pingidentity.com/en/signup.html> -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object
ailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986126557&sdata=I5KDQT%2BdT0lapMOr71odsiCRrZ7csVZMuaYnMzsWwhM%3D&reserved=0> >> > >> >> > >> ___ >> > >> OAuth mailing list >> > >> OAuth@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/oauth >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986136551&sdata=8nJdrY3H98I39l5KXVkokwGw9sVzQGTJRfoxYwjtLhs%3D&reserved=0> >> > > >> > > ___ >> > > OAuth mailing list >> > > OAuth@ietf.org >> > > https://www.ietf.org/mailman/listinfo/oauth >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986136551&sdata=8nJdrY3H98I39l5KXVkokwGw9sVzQGTJRfoxYwjtLhs%3D&reserved=0> >> > >> >> > ___ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986146548&sdata=%2B1PGj7U2CLMlh6HWf8BuGIvqtcGkz0hLMJYlktmkLc4%3D&reserved=0> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986156545&sdata=2lgFg7%2F%2BLZ%2FgoabHcpK1ggg1FgNaArMIUKojGxJ%2BdLk%3D&reserved=0> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> <https://nam06.safelinks..protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986166540&sdata=Ex9kDYE8r4E0Y2KxMdDpwtZVWdNrq1Uqm6eYFf1LcsI%3D&reserved=0> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnat.sakimura.org%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986166540&sdata=%2FEt7X7DH8psh0JPtSnZGyk6qtliZUySH4z9%2BbLAEeTs%3D&reserved=0> >> @_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 >> > > *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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > -- > Vladimir Dzhuvinov > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Rob Otto EMEA Field CTO/Solutions Architect roberto...@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image: LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter logo] <https://twitter.com/pingidentity> [image: facebook logo] <https://www.facebook.com/pingidentitypage> [image: youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image: Blog logo] <https://www.pingidentity.com/en/blog.html> <https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ> <https://www.pingidentity.com/en/events/d/identify-2019.html> <https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf> <https://www.pingidentity.com/en/events/e/rsa.html> <https://www.pingidentity.com/en/events/e/rsa.html> <https://developer.pingidentity.com/en/signup.html> -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1
I'd imagine you have to pre-register each client and then use HOTP or TOTP to generate one-time passcodes. On Thu, 9 Apr 2020 at 08:25, Daniel Fett wrote: > Hi Francis, > > Am 08.04.20 um 23:59 schrieb Francis Pouatcha: > > As a replacement of RFC 6749 I am missing a "Direct Grant" with the same > simplicity as the "Resource Owner Password Credentials" grant of RFC 6749.. > > The reason is that browser redirects are too complex and most of the time > badly implemented by small teams. For the sake of having SMEs use oAuth 2..1 > with their limited development capacities, I suggest keeping the simple > "Resource > Owner Password Credentials" with an OTP replacing the permanent password. > > How does the Client get the OTP in that case? > > -Daniel > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Rob Otto EMEA Field CTO/Solutions Architect roberto...@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image: LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter logo] <https://twitter.com/pingidentity> [image: facebook logo] <https://www.facebook.com/pingidentitypage> [image: youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image: Blog logo] <https://www.pingidentity.com/en/blog.html> <https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ> <https://www.pingidentity.com/en/events/d/identify-2019.html> <https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf> <https://www.pingidentity.com/en/events/e/rsa.html> <https://www.pingidentity.com/en/events/e/rsa.html> <https://www.pingidentity.com/en/lp/e/enabling-work-from-home-with-MFA.html> *If you’re not a current customer, click here <https://www.pingidentity.com/en/lp/e/work-from-home-sso-mfa.html?utm_source=Email&utm_campaign=WF-COVID19-New-EMSIG> for a more relevant offer.* -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
eceives for a new token that it can use to call a downstream > >> service. And that service in turn might do another exchange to get a new > >> token suitable to call yet another downstream service. And again and so > on > >> and turtles all the way. I'm not necessarily endorsing that level of > >> granularity in chaining but it's bound to happen somewhere/sometime. The > >> nested actor claim is able to express that all that has happened with > the > >> top level or outermost one being the system currently using the token > and > >> prior systems being nested.. What actually gets done with that > information > >> is up to the respective systems involved. There might be policy about > what > >> system is allowed to call what other system that is enforced. Or maybe > the > >> info is just written to an audit log somewhere. Or something else. I > don't > >> know. But whatever it is application/deployment/policy dependent and not > >> specifiable by a spec. > >> > >> > >> > >> > >> > >> > >> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla wrote: > >>> > >>> Hi folks, > >>> > >>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem > >>> generally OK. I do still have one remaining concern, which is about > >>> the actor claim. Specifically, what is the RP supposed to do when they > >>> encounter it? This seems kind of underspecified. > >>> > >>> In particular: > >>> > >>> 1. What facts am I supposed to know here? Merely that everyone in > >>>the chain signed off on the next person in the chain acting as them? > >>> > >>> 2. Am I just supposed to pretend that the person presenting the token > >>>is the identity at the top of the chain? Say I have the > >>>delegation A -> B -> C, and there is some resource which > >>>B can access but A and C cannot, should I give access? > >>> > >>> I think the first question definitely needs an answer. The second > >>> question I guess we could make not answer, but it's pretty hard > >>> to know how to make a system with this left open.. > >>> > >>> -Ekr > >>> > >>> > >>> ___ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> 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 > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> ___ > >> OAuth mailing list > >> OAuth@ietf.org > >> 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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Bill Burke > Red Hat > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Rob Otto EMEA Field CTO - Ping Identity +44 777 135 6092 -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"
I support this as well On Fri, 20 Jul 2018 at 15:22, Brian Campbell wrote: > +1 > > On Thu, Jul 19, 2018 at 1:51 PM, William Denniss < > wdenniss=40google@dmarc.ietf.org> wrote: > >> I support adoption of this document by the working group. >> >> >> On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef < >> rifaat.i...@gmail.com> wrote: >> >>> Hi all, >>> >>> This is the call for adoption of the 'JWT Response for OAuth Token >>> Introspection' document following the presentation by Torsten at the >>> Montreal IETF meeting where we didn't have a chance to do a call for >>> adoption in the meeting itself. >>> >>> Here is presentation by Torsten: >>> >>> https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00 >>> >>> Here is the document: >>> >>> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01 >>> >>> Please let us know by August 2nd whether you accept / object to the >>> adoption of this document as a starting point for work in the OAuth working >>> group. >>> >>> Regards, >>> Hannes & Rifaat >>> >>> ___ >>> 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 >> >> > > *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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Rob Otto EMEA Field CTO/Solutions Architect roberto...@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image: LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter logo] <https://twitter.com/pingidentity> [image: facebook logo] <https://www.facebook.com/pingidentitypage> [image: youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo] <https://plus.google.com/u/0/114266977739397708540> [image: Blog logo] <https://www.pingidentity.com/en/blog.html> <https://www.gartner.com/doc/reprints?id=1-5423XKW&ct=180620&st=sb> -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth