[OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JWT Response for OAuth Token Introspection Authors : Torsten Lodderstedt

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-04.txt

HI all, this revision incorporates changes based on the AD's feedback. kind regards, Torsten. > On 22. Jul 2019, at 12:37, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authori

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03

Hi Roman, thanks a lot for your review feedback. I just published a new revision of the draft incorporating changes based on your comments. https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-04 > On 17. Jul 2019, at 18:17, Roman Danyliw wrote: > > Hi! > > The followi

Re: [OAUTH-WG] Refresh tokens

> FWIW, in addition, those can be used together -- sliding & absolute.  Azure AD does both at this point. They used to do 90 days absolute, now it is a sliding, 72 hours by default I believe.  Good discussion overall, would this be a good summary for the type of a client the spec is for: SHOUL

Re: [OAUTH-WG] Refresh tokens

Thank you both for your replies, my responses are below: On 20 Jul 2019, at 19:54, David Waite wrote: > >> On Jul 20, 2019, at 12:38 PM, Leo Tohill wrote: >> >> Access tokens and refresh tokens, stored browser-side, are equally >> vulnerable to theft, because the storage options are identical

Re: [OAUTH-WG] Refresh tokens

Hi Neil, > On 22. Jul 2019, at 13:59, Neil Madden wrote: > >> In addition, a public client which does not use its refresh token in an >> “offline” manner may have theft go unnoticed for a considerable period of >> time, and the operational model of public clients usually puts detection of >>

Re: [OAUTH-WG] Recommended OpenId Connect Flow for SPA with Microservices

Hi David, > On 12. Jun 2019, at 04:01, David Waite wrote: > > To prevent exfiltration, the options are limited. > - Token Binding will work, but only currently has support in Edge. > - Mutual TLS will work, but has a poor experience unless you are deploying > alongside group policy. > - DPoP

Re: [OAUTH-WG] Query on RFC 7009

Hi James, > On 11. Jun 2019, at 17:53, James Howe wrote: > > Unless I'm mistaken, RFC 7009 doesn't specify the error response when the > request is from a different client to the issuer. > > Section 2.1: >> If this validation fails, the request is refused and the client is informed >> of the

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

Yes, sorry about that. I realized this yesterday and as tried to write quickly from from my phone just before my flight took off for Montreal , I'd gotten distracted with the question of what to do with the registrations and l

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

Hi Brian! From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, July 22, 2019 8:37 AM To: Roman Danyliw Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 Yes, sorry about that. I realized this yesterday and as tried to write quickly f

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

Hi Aaron, thanks for your continued work on the topic. Here are some general remarks on the current revision: 1) This BCP should not be limited to public clients. Your BCP itself already describes an architecture where the OAuth client is a backend that may be a confidential client (see sec

Re: [OAUTH-WG] Transaction Authorization

> On 21 Jul 2019, at 22:22, Dick Hardt wrote: > > Hi Neil, I agree that an access token that is usable across resources is > problematic. > > How are you thinking multiple access tokens would be returned? Well there are lots of possible ways, e.g.: { "tokens": [ { "resource": "https://re

[OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

Hi Roman, Thanks again for sticking with me through this one with and associated registry updates with token exchange as well as my temporarily overlooking some needed changes. -04 is now up and this time I think I've actually

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

Hi Brian! The -04 version addresses my remaining concerned. Thanks for this update. I’ve advanced the document to IETF LC. Roman From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, July 22, 2019 9:47 AM To: Roman Danyliw Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD Review

Re: [OAUTH-WG] Recommended OpenId Connect Flow for SPA with Microservices

Hi Thorsten, do you mean that for service2service communication or for the frontend to backend communication? How would that process look like in a nutshell? Thanks! David Am 22. Juli 2019 14:30:41 MESZ schrieb Torsten Lodderstedt : >Hi David, > >> On 12. Jun 2019, at 04:01, David Waite >

[OAUTH-WG] Last Call: (Resource Indicators for OAuth 2.0) to Proposed Standard

The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'Resource Indicators for OAuth 2.0' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substa

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt

Hi Vittorio, thanks for contributing this specification. It fills a further gap in the OAuth universe :-) Here are my comments: - 2.2.1 there are other sources for identity claims, e.g. https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html. I recommend to open the clause "An

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt

Thank you Torsten for the prompt review and insightful comments! 2.2.1 - excellent point. I added the suggested language. 2.2.2 - interesting. I did think of cases similar to profile in OIDC, where the effect of the request is influencing the layout of the resulting idtoken, but concluded that it

[OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-jpop-05.txt

Just refreshed the JPOP draft as it may be pertinent to both DPOP and access token JWT discussion. Nat Sakimura Nomura Research Institute PLEASE READ：This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete

Re: [OAUTH-WG] Transaction Authorization

+1 Also, if it were to include user identification in the protocol, I would like to have the spec at least cover the following: 0. User 1. External Identity Provider 2. Resources that covers the functionality of PEP. 3. Authorization Server that act as PDP for Resources. 4. Internal Identity Ser

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt

> On 22. Jul 2019, at 17:13, Vittorio Bertocci > wrote: > > Thank you Torsten for the prompt review and insightful comments! > > 2.2.1 - excellent point. I added the suggested language. > > 2.2.2 - interesting. I did think of cases similar to profile in OIDC, where > the effect of the reque

Re: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.

I think the implication is that the server-side would use something like OIDC to the token server in order to establish the identity of the user. The difference is that this would be driven from the server-side piece of the application, as any other normal server-side client would. The result wo

Re: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.

+1, as discussed before Hans. On Mon, Jul 22, 2019, 18:25 Brock Allen wrote: > I think the implication is that the server-side would use something like > OIDC to the token server in order to establish the identity of the user. > The difference is that this would be driven from the server-side p

[OAUTH-WG] little nit on draft-ietf-oauth-security-topics-13 wrt ietf-oauth-mtls

The description of I-D.ietf-oauth-mtls in https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8..1.2 talks about binding to and checking against the fingerprint of the public key from the client certificate. However, https://tools.ietf.org/html/draft-ietf-oauth-mtls-15 uses a

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt

> Additionally stating that unique audiences shall be used for different services should be ok. Fair! I'll add language to that effect in section 5 and update the draft before Friday. thanks! V. On Mon, Jul 22, 2019 at 9:25 AM Torsten Lodderstedt wrote: > > > > On 22. Jul 2019, at 17:13, Vittori

[OAUTH-WG] (no subject)

___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization

Hi Neil I see that you are looking at how to modify Justin's proposal, and I'm looking at what are the requirements. Ignoring the specifics, is there a reason why multiple tokens need to be returned in the same request? On Mon, Jul 22, 2019 at 9:41 AM Neil Madden wrote: > > On 21 Jul 2019, at

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03

Hi Torsten! > -Original Message- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Monday, July 22, 2019 6:59 AM > To: Roman Danyliw > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection- > response-03 > > Hi Roman, > > thanks a

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03

Hi Torsten! Separately from the below, idnits is troubled by the lack of an RFC2119 section and the presence or absence of some reference despite citation: ==[ snip ]== Miscellaneous warnings: == The document seem

Re: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.

I didn't see the earlier discussion (do you have a date or title?) so apologies if I'm bringing up something that's been resolved. But I still think that it's really confusing to say "it may be a better decision to avoid using OAuth entirely" if the application will still be using Oauth/OIDC (whi

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

I agree that there's a problem regarding the scope of this BCP . Or at least, I'm confused. Is this BCP supposed to be all about the architecture where the browser holds the token(s)? If so, then a) let's just put that out front and center: that's the context of this BCP. That's what's meant by

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt

thanks > Am 22.07.2019 um 21:32 schrieb Vittorio Bertocci : > > > Additionally stating that unique audiences shall be used for different > > services should be ok. > Fair! I'll add language to that effect in section 5 and update the draft > before Friday. > thanks! > V. > >> On Mon, Jul 22,