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

Vectors of Trust was meant to be used in place of things like AuthenticationContextReference (acr) and its kin, so this is a fair assessment. It does still require a shared understanding of what a given vector means by processing it in the context of its trust mark. — Justin > On Dec 23, 201

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I think the nature of the backwards incompatibility is important here. The way that things are now, using merge-with-precedence, you have the following matrix of compatibility: New Server | Old Server | ---+-+--+ New Client | YES| NO

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

t inside the signed request > object passed in the request or request_uri parameter; > > instead of just saying "the authorization server supporting this > specification MUST only use the parameters included in the request object." > which will bring about [Problem 3-1

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

zation request outside of request object will be treated as >> non-OAuth parameters. >> >> Nat Sakimura >> Research Fellow, Nomura Research Institute >> E: n-sakim...@nri.co.jp <mailto:n-sakim...@nri.co.jp> >> T: +81(90)60136276 >> --------- >> PLEASE READ:Thi

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests

+1 With the comment that there’s going to be a lot of coordination between this and other components already in OAuth 2 (scope, resource, aud/audience, JAR stuff) and anything that might come out of TxAuth. Those are two of my main goals as co-author of this work. — Justin > On Jan 6, 2020,

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metadata

I just want to add that the requirement to validate the request at PAR the same way as you would at the auth endpoint is something that I want to see relaxed, and I hope it doesn’t make it through to the final standard. Also keep in mind that this is barely started as a WG document so any requ

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

But merge gives us the ability, which has been stated here before, to have a fixed core set of parameters inside the JAR and a mixed set of variable parameters outside the JAR. What if by “merge” we really mean “you can’t repeat things in both places but you can have fields in either”. — Just

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: PAR metadata

+1 to this being a security consideration — Justin > On Jan 8, 2020, at 3:46 PM, Richard Backman, Annabelle > wrote: > > I almost included text to that effect, but thought it was getting too wordy. > However your suggestion is simple and concise. +1 > > Given all of this discussion, we shou

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

I would argue that the AS being monolithic, as seen by outside parties, is a core assumption in OAuth 2. While there are deployments that, for example, split the authorization and token endpoints into different domains and servers, the client still sees them as a single entity. I think it’s fa

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

So we could solve this by saying the resulting data object of a PAR is a request object. Which might also contain a request object internally as well. In that case JAR should back off from saying it’s a JWT and instead say it’s a request object. Or we define a new term for this authorization req

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

what the request_uri / object is, it > would be great. > > > > The normative language I think should focus on maintaining the OAuth 2.0 > contract for the entire logical authZ request, together with the basic > contracts of 1) JAR and the 2) authZ endpoint. > > &g

Re: [OAUTH-WG] RAR & multiple resources?

Multiple access tokens are outside the scope of RAR. The request is intended to describe the access for a single returned access token. If semantics for multiple access tokens are agreed upon, then it can use the RAR structure, the Resources parameter, and the Scope parameter all in parallel aga

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

I would rather see extensions define a key ID than a new key set URI. Otherwise what’s the point of having more than one key in the set, with unique identifiers? It would’ve been nice if JWK could’ve agreed on a URL-based addressing format for individual keys within the set, but that ship’s sai

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

ally been published yet. > > – > Annabelle Richard Backman > AWS Identity > > > From: OAuth mailto:oauth-boun...@ietf.org>> on > behalf of Vladimir Dzhuvinov <mailto:vladi...@connect2id.com>> > Organization: Connect2id Ltd. > Date: Wednesday, January

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

1/2020 04:25, Justin Richer wrote: >> It would’ve been nice if JWK could’ve agreed on a URL-based addressing >> format for individual keys within the set, but that ship’s sailed. > > For querying / selecting JWKs from a set this would have been a useful > addition to the spec.

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

nce they can use the standard library >> function for request objects to pass the PAR reference to the AS. Is this >> worth the trouble? >> >>> Am 16.01.2020 um 16:48 schrieb Justin Richer >> <mailto:jric...@mit.edu>>: >>> >>> +

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

I don’t agree with this stance from a security or implementation perspective. If there’s a clear order of precedence for the information, it’s not particularly problematic. Everything inside the request object is to be taken over things outside the request object. We have the exact same semanti

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

t; suggestion to say that if a parameter is both inside the request object and >> outside and they do not match, reject the request as suspicious. >> >>> On Jan 17, 2020, at 5:45 AM, Justin Richer wrote: >>> >>>  I don’t agree with this stance f

[OAUTH-WG] HTTP Signing

As many of you know, Annabelle and I have put forward a general-purpose HTTP Signing specification in the HTTP Working Group, at least initially based on the old Cavage signatures spec that’s been used in the wild. We expect a number of important changes to happen as it goes through the standard

Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping password grant

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 > wrote: > > I would suggest a SHOULD NOT instead of MUST, there are still sites using > this and a grace pe

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

es you mentioned? >>>>>>>> >>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden >>>>>>>>> : >>>>>>>>> >>>>>>>>> I very much agree with this with regards to real users.

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

Your interpretation was our intent with that. It’s a full replace of the object. We had debating having PATCH style semantics, but ultimately decided that that was too complex for the most common update actions that a client would have. — Justin > On Mar 3, 2020, at 8:42 AM, Filip Skokan wro

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

kokan > > > On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki <mailto:t...@authlete.com>> wrote: > Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the same > concerns in this mailing list about 6 months ago (on Sep. 4, 2019). RFC 8707 > didn't

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Rdis" > }, > "sub":"123456789087632345678" > } > } > > The response for inactive tokens would look like this: > > { > "iss":"https://as.example-bank.com";, > "aud":"6a256bca-1e0b-4b0c-84fe-c9

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

x27;s request to delete them from the client's registration. > > Does not mean the server needs to accept requests where fields are omitted? > Is that a left over from previous drafts then? > > S pozdravem, > Filip Skokan > > > On Wed, 4 Mar 2020 at 16:37,

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

recki.com/> >>>>> @aaronpk >>>>> >>>>> >>>>> >>>>> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell >>>>> >>>> <mailto:40pingidentity@dmarc.ietf.org>> wrote: >>>>> Co

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

issues but we got lucky that there weren’t the same kind of conflicts that we see here. — Justin > On Mar 4, 2020, at 11:49 AM, Torsten Lodderstedt > wrote: > > no particular reason, just indicating special meaning. I can live without it. > >> Am 04.03.2020 um 17:29

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

handled, but in the same section earlier it states > that all fields must be included. > > S pozdravem, > Filip Skokan > > > On Wed, 4 Mar 2020 at 17:35, Justin Richer <mailto:jric...@mit.edu>> wrote: > I’m not sure what you’re asking — the text is not le

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Why would the client need to know the refresh token’s expiry? Can’t they just use the refresh token and see? Either way it’s a single round trip to the AS and the client gets the same answer with the same recovery code path. — Justin > On Mar 4, 2020, at 2:01 PM, Bill Jung > wrote: > > The

Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow

I for one appreciate it being a separate draft as I don’t agree with this solution but do think we should move forward with DPoP. — Justin > On Mar 10, 2020, at 6:40 AM, Rifaat Shekh-Yusef wrote: > > Mike, > > What was the reason for creating a separate draft for this? > Why cannot this be f

Re: [OAUTH-WG] Corona Virus and Vancouver

I plan to be in Vancouver unless the IETF meeting itself is cancelled. — Justin > On Mar 9, 2020, at 2:33 PM, Daniel Fett wrote: > > Hi all, > > can we do a quick roll call on who is coming or not coming to Vancouver? > > For me, at the current point in time, it depends on whether a signific

Re: [OAUTH-WG] Call for Adoption: DPoP

+1 I support adoption of DPoP. I have written an implementation of its current state for a client and implemented its signature mechanism in another project (without the rest of the protocol, fwiw). Now, speaking as the editor of the group’s previous general-purpose http signature draft (for

Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?

OpenID Connect is based on OAuth 2.0, not on OAuth 2.1. Therefore, it would not be affected at all, whether through the hybrid or implicit flows. If OIDC pushes a revision to OAuth 2.1, then it would be bound by the features of OAuth 2.1 and would need to contend with that. But until that happen

Re: [OAUTH-WG] RAR - Example JWT for Payment

The “type” is effectively a schema marker for the content of the authorization request object, and so it doesn’t need to be the same domain as the API that’s being hosted. Think of it this way: the type defines the API, this could be a standard body or some other org, and the location defines th

Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments

I want to add my perspective to the question of audience restriction, below: One of the problems with implementing audience restriction of RS’s in the wild has actually turned into a problem of audience identification instead. In other words, the client needs to know some identifier that the RS

Re: [OAUTH-WG] Dealing with oAuth redirect_uri in draft-parecki-oauth-v2-1 and need for AS back channel initiation endpoint

Francis, The backchannel-first pattern that you are discussing is one of the key components of TxAuth, which we are discussing on the txa...@ietf.org mailing list, and I invite you to join the conversation there. I have a project to implement these ideas that’s document

Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1

We’ve looked at this with XYZ, and one of the patterns that’s possible with the backchannel-first flow is to have the server send a challenge back to the client which the client can then respond to, for example by signing it with a FIDO style device key. Depending on the system, the client could

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

The idea of “Continuing to work without taking advantage of sender constraints” is, I would argue, a security hole. Systems are allowed to fail security checks but still offer functionality. This is exactly the pattern behind allowing an unsigned JWT because you checked the “alg" header and it w

Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?

I agree that any URI could be used but that it MUST be understood by the AS to be local to the AS (and not something that can be impersonated by an attacker). I wouldn’t even go so far as RECOMMENDED, but it’s certainly an option. — Justin > On Apr 27, 2020, at 4:41 AM, Filip Skokan wrote: >

Re: [OAUTH-WG] carrying oauth authorisation without HTTP

It depends on what protocol you’re using on the socket connection between the client (the home router) and the RS/AS. You’ll need :someplace: to put the access token. RFC6750 and RFC8705 are explicitly about HTTP so you can’t use them directly, but other work (like that done in the ACE group wit

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

What if we simply declare that refresh tokens are always bound to the DPoP key used to request them? Is there value in NOT binding the refresh token? As for access tokens, the way I read it, all of this is true: - The AS could still decide to issue a Bearer token, using the token_type field, fo

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

The two-phase approach is exactly what OBUK does, where you get one access token using client credentials before getting a more specific one in context of the user’s consent. This ends up being awkward to implement at best, since OAuth involves the user too early in the process to allow for this

[OAUTH-WG] OAuth Request JSON Encoding

In the ten years since OAuth started, we’ve seen a huge shift away from form encoding to JSON encoding for sending data to a server. And yet, OAuth is stuck with form encoding. So I thought, why can’t we change that? I put together a quick proposal for how this would work. https://www.ietf.org/

Re: [OAUTH-WG] OAuth Request JSON Encoding

om authorization_details > param sent to the token endpoint form encoded i don’t find much unnatural > about the existing oauth interface. > > Filip > > Odesláno z iPhonu > >> 9. 7. 2020 v 21:29, Justin Richer : >> >>  >> In the ten years since OAuth

Re: [OAUTH-WG] OAuth Request JSON Encoding

Odesláno z iPhonu > >> 13. 7. 2020 v 18:09, Justin Richer : >> >> The intent was to only affect the request, not the response, though I can >> see the confusion that would arise in having those be at odds with each >> other. >> >> — Justin >&

[OAUTH-WG] Namespacing "type" in RAR

The “type” field in the RAR spec serves an important purpose: it defines what goes in the rest of the object, including what other fields are available and what values are allowed for those fields. It provides an API-level definition for requesting access based on multiple dimensions, and that’s

Re: [OAUTH-WG] Namespacing "type" in RAR

> again, the details are out of scope of GNAP, but we can provide examples to > guide implementers. > > Are you still thinking that bare strings are allowed in GNAP, and are defined > by the AS? > > > > On Fri, Jul 17, 2020 at 8:39 AM Justin Richer <mailto:jric

Re: [OAUTH-WG] Namespacing "type" in RAR

still just be a string, but we can help people make better decisions about what to put in that string. — Justin > On Jul 17, 2020, at 2:13 PM, Vladimir Dzhuvinov > wrote: > > > On 17/07/2020 17:38, Justin Richer wrote: >> And all that brings me to my proposal: >> >

Re: [OAUTH-WG] Namespacing "type" in RAR

er of these > would be at run time. JSON Schema allows comments and examples. > > What is the harm in non-normative language around a retrievable URI? > > BTW: the example in > https://oauth.xyz/draft-richer-transactional-authz#rfc.section.2 > <https://oauth.xyz/draft-rich

Re: [OAUTH-WG] Namespacing "type" in RAR

I created a pull request with some proposed language here: https://github.com/oauthstuff/draft-oauth-rar/pull/52 <https://github.com/oauthstuff/draft-oauth-rar/pull/52> — Justin > On Jul 20, 2020, at 7:42 AM, Justin Richer wrote: > > Since this is a recommendation for name

Re: [OAUTH-WG] Namespacing "type" in RAR

> > A byte comparison, as you suggested earlier, will be problematic, as I have > pointed out. > > I'm confused why you are still talking about the AS retrieving a URI. > > ᐧ > > On Mon, Jul 20, 2020 at 4:42 AM Justin Richer <mailto:jric...@mit.edu>> wrot

Re: [OAUTH-WG] Namespacing "type" in RAR

> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov > wrote: > > On 18/07/2020 17:12, Justin Richer wrote: >> I think publishing supported “type” parameters isn’t a bad idea, and it >> aligns with publishing supported scopes and claims in discovery. > If you are a d

Re: [OAUTH-WG] Namespacing "type" in RAR

ld retrieve > the URI. I HAVE NOT SAID THAT! > > I am suggesting that the URI MAY be retrievable, and I gave examples on how > that would be useful for tooling for client developers, and for an AS in > doing input validation. The URI would NOT be retrieved at run time.

Re: [OAUTH-WG] Namespacing "type" in RAR

schema for input validation. Neither of these > would be at run time. JSON Schema allows comments and examples. > > What is the harm in non-normative language around a retrievable URI? > > On Tue, Jul 21, 2020 at 9:58 AM Justin Richer <mailto:jric...@mit.edu>> wrote: >

Re: [OAUTH-WG] Namespacing "type" in RAR

that have multiple code points? Or that they only > use english? > > > > On Tue, Jul 21, 2020 at 10:34 AM Justin Richer <mailto:jric...@mit.edu>> wrote: > Right, and I’m saying that all three of those would be DIFFERENT “type” > values, because they’re different str

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

An RS is not considered an OAuth 2 client, though there’s enough overlap in the structure that I know several implementations that store RS records in the same table as the client records with a special flag set on them to differentiate. The RS <-> AS communication channel has never really gotte

Re: [OAUTH-WG] Namespacing "type" in RAR

>> On 22. Jul 2020, at 22:16, Vladimir Dzhuvinov >> wrote: >> >> >> On 21/07/2020 18:43, Torsten Lodderstedt wrote: >>> >>>> On 21. Jul 2020, at 17:40, Vladimir Dzhuvinov >>>> wrote: >>>> >>>> >>

Re: [OAUTH-WG] Namespacing "type" in RAR

o a registry of the > elements that can make up that content that are general across type. I don't > see how to reconcile that. > > On Mon, Jul 20, 2020 at 10:00 AM Justin Richer <mailto:jric...@mit.edu>> wrote: > I created a pull request with some proposed language

Re: [OAUTH-WG] Namespacing "type" in RAR

gt; I therefore don’t see the need for a RAR specific mechanism (a registry). > > best regards, > Torsten. > >> Am 26.07.2020 um 02:48 schrieb Justin Richer : >> >> Brian, >> >> I can appreciate the confusion on the elements registry. It’s really about

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

the client doesn't have to mess with building URLs, and >> actually provides additional flexibility for the AS as well since that >> endpoint no longer needs to be the exact same URL as the authorization >> endpoint.. >> >> --- >> Aaron Parecki >>

[OAUTH-WG] OAuth v.2.1 Readthrough

As promised on the WG call, I’ve gone through the 2.1 document and I’ve made some notes and suggestions on my way through. A big thanks to the editors for putting this together, and particularly for Aaron who did the early heavy lifting on getting a reasonable start on this important work! But

[OAUTH-WG] WGLC Review of PAR

I’ve done a full read through of the PAR specification, and here are my notes on it. For additional context, I’ve implemented this specification for both a client and a server in a couple of languages. Overall, I think it’s in good shape and it makes sense from a developer’s perspective. I’ve g

Re: [OAUTH-WG] WGLC Review of PAR

gt; > On Wed, Aug 19, 2020 at 2:06 PM Justin Richer <mailto:jric...@mit.edu>> wrote: > I’ve done a full read through of the PAR specification, and here are my notes > on it. > > For additional context, I’ve implemented this specification for both a client > and a server in

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

I would argue that by the nature of OAuth tokens not being bound to user presence or sessions, it’s not an indication that the user is present necessarily, unless you know something additional about the nature of the client. But it does tell the AS when the client is active for a particular AS,

Re: [OAUTH-WG] WGLC Review of PAR

> with lots of content that needs no further discussion removed). > > A TL;DR for the WG is that I'd like to get some wider feedback on the > question of changing the one-time-use condition on the request_uri from a > SHOULD to a MUST. > > On Tue, Aug 25, 2020 at 4:57 P

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

I would clarify that this doesn’t necessarily say that the user’s there, and remove the normative requirement (which doesn’t have enforceable teeth in this context): Implementers should be aware that a token introspection request lets the AS know when the client (and potentially the user)

Re: [OAUTH-WG] WGLC Review of PAR

I completely agree with the utility of the function in question here and it needs to be included. I’m in favor of creating a dedicated section for redirect_uri management, so that we can explain exactly how and why to relax the requirement from core OAuth. In addition, I think we want to discuss

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

r is using > the client. If this implication is not acceptable, implementers can use > other means to carry > access token data, e.g. directly transferring the data needed by the RS > within the access token. > ᐧ > > On Thu, Aug 27, 2020 at 7:19 AM Justin Richer

Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?

I’m not sure that adding this amount of text to the privacy considerations section is appropriate for an errata. If we wanted to do this, I believe we’d need to do a new revision of 7662. — Justin > On Sep 2, 2020, at 4:39 AM, Denis wrote: > > Hi Ben, > > This new thread, i.e."Towards an RF

Re: [OAUTH-WG] WGLC Review of PAR

so > useful in situations where client ids and correspoding credentials and > policies are managed by a trusted 3rd party, e.g. via client certifiates > containing client permissions. Such an externally managed client could > interact with an AS trusting the respective 3rd party

Re: [OAUTH-WG] WGLC Review of PAR

Nice work, Brian. Looks good to me! From: Brian Campbell [bcampb...@pingidentity.com] Sent: Wednesday, September 2, 2020 3:41 PM To: Justin Richer Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth Subject: Re: [OAUTH-WG] WGLC Review of PAR Thanks Torsten

Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request

In my opinion, all parameters should be able to be passed inside the request object, including `scope`. We couldn’t do that kind of thing in OIDC because that would be a breaking change to existing requirements in OAuth 2. JAR is taking the step of overriding those requirements, and so it shou

[OAUTH-WG] Token substitution in DPoP

While working on an implementation of DPoP recently, I realized that the value of the access token itself is not covered by the DPoP signature at all. What I’m wondering is whether or not this constitutes an attack surface that we care about here. Here’s how it works: Let’s say that a client c

Re: [OAUTH-WG] Token substitution in DPoP

rant and not the > client's key. Therefore, a client may use a different key per token. At least > this is an approach we are following. > > Best, > Nikos > > -Original Message----- > From: OAuth On Behalf Of Justin Richer > Sent: Friday, November 20, 20

Re: [OAUTH-WG] Token substitution in DPoP

es in the future and exfiltrate them in conjunction >>with a token. These stolen artifacts can later be used together >>independent of the client application to access protected resources. >>The impact of such precomputed DPoP proofs can be limited somewhat by >&

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

I went and implemented this proposal of including a token hash in both an AS (java) and client (javascript) on a system that was already using DPoP and OpenID Connect. What I did there was just use the existing code we had on the AS-side to calculate the “at_hash” in the ID Token from OIDC, whic

Re: [OAUTH-WG] Tenancy in OAuth

Hi Jaap, There have been a number of efforts to address this kind of thing in the OAuth world. You can definitely use a special scope to encode this value, which has the benefit of fitting into the implementation limitations of nearly all OAuth systems out there. The “resource” parameter can al

Re: [OAUTH-WG] Rich Authorization Requests feedbacks on implementation

Hi Nicolas, > On Jan 10, 2021, at 8:36 PM, Nicolas Mora > wrote: > > Hello, > > I've implemented Rich Authorization Requests defined in > draft-ietf-oauth-rar-03 for Glewlwyd soon-to-be-released 2.5 [1], and I > humbly wanted to write my feedback about this implementation to share my > expe

[OAUTH-WG] Authorization Header Encoding

The HTTP Working Group opened an issue for discussion in relation to the updated HTTP semantics specification. The core of the issue is the format of the “Authorization” header, which of course gets used by the “Bearer” scheme defined in RFC6750. https://github.com/httpwg/http-core/issues/733

[OAUTH-WG] Digest for DPoP

Two different specifications (GNAP and FAPI signatures) have recently profiled DPoP to use its signature method to protect a different kind of protocol entirely. One thing these methods have in common is that they both define an additional field for holding a digest of the HTTP Message Body: ht

Re: [OAUTH-WG] Authorization Header Encoding

ating the Bearer header definition in OAuth 2.1 seems like the > most sensible move. I expect OAuth 2.0 implementers who maintain their > software to pick up the 2.1 spec, sooner or later. > > Vladimir > > > > On 12/02/2021 00:01, Justin Richer wrote: >> The HTTP Working G

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

I agree that the NxM problem is the purview of the whole IETF, but it’s something that we’re particularly interested in over in GNAP. As the editor of OAuth’s dynamic registration extension and the GNAP core protocol, I hope I can add to this conversation. From a technical standpoint, OAuth’s d

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

> On Feb 25, 2021, at 2:59 PM, Evert Pot wrote: > On 2021-02-25 3:41 a.m., Seán Kelleher wrote: >> Yep, this is the big point - OAuth is designed to require the the third leg >> of trust that creates the NxM problem. >> >> I believe the snippet of Justin's that you quoted actually shows you how

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

"problem" part of the NxM > problem. > > As such, I would actually suggest constraining this discussion to just the > POP NxM problem rather than NxM in general because, for me at least, the > authZ part of the general case is the most "solved" part of the prob

Re: [OAUTH-WG] One-time token login

I agree that it seems strange to use the authorization code in such a manner, though I can see how it could work on a technical basis. While it’s not an exact match, you might want to look at the Device Grant: https://tools.ietf.org/html/rfc8628 Here you i

[OAUTH-WG] Access Token Hash for DPoP

As discussed on the call yesterday, I have put together a modest proposal for adding access token hash to the DPoP draft. https://github.com/danielfett/draft-dpop/pull/62 Instead of using the existing OpenID Connect “at_hash” claim and definiti

Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-03.txt

As mentioned, my own intention for using a new claim “ath” was to have a fixed hash size, not dependent on the surrounding JWS envelopes that “at_hash” is based on. I’ve implemented both approaches on several platforms now, and I greatly prefer the fixed hash. It’s a new name because it is a n

[OAUTH-WG] HTTP Message Signing and OAuth PoP

Many of you will remember an old draft that I was the editor of that defined OAuth proof of possession methods using HTTP Message Signing. When writing that draft I invented my own scheme because there wasn’t an existing HTTP message signature standard that was robust enough for our use cases. I

Re: [OAUTH-WG] HTTP Message Signing and OAuth PoP

scuss this. > Do you have a date in mind? > > Regards, > Rifaat & Hannes > > > > > > On Thu, Apr 29, 2021 at 11:34 AM Justin Richer <mailto:jric...@mit.edu>> wrote: > Many of you will remember an old draft that I was the editor of that defi

Re: [OAUTH-WG] Can a client send the Authorization Request?

One point, the client doesn’t POST to the authorization endpoint, the resource owner’s browser is supposed to POST to the authorization endpoint — it’s an important distinction. And in the wild, this is really rare to see in use. As written, this is not compliant with OAuth2. I agree that this s

Re: [OAUTH-WG] Can a client send the Authorization Request?

and/or opening new potential attack vectors, if that's also the > case - still trying to figure that one out). Is there any flaw in OAUTH2 that > would require such mTLS on this endpoint? Is it worth the risks involved in > deviating from the normal flow? > > Thanks, >

Re: [OAUTH-WG] Can a client send the Authorization Request?

I'm actually wondering if we should add discussion about not putting mtls on the authorisation endpoint into OAuth 2.1. Aaron et al, thoughts? -Justin From: A. Rothman [amich...@amichais.net] Sent: Tuesday, May 25, 2021 7:03 PM To: Justin Rich

Re: [OAUTH-WG] Can a client send the Authorization Request?

e language >> around the authorization endpoint needing to be accessible by the user agent >> without MTLS or other funny stuff. >> >> PAR also fits in nicely in that case since the PAR endpoint could be >> protected with MTLS since it *is* intended to only

[OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-httpsig-00.txt

0.txt > Date: June 21, 2021 at 11:52:14 AM EDT > To: "Justin Richer" > > > A new version of I-D, draft-richer-oauth-httpsig-00.txt > has been successfully submitted by Justin Richer and posted to the > IETF repository. > > Name: draft-richer-oauth-httpsig

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (6613)

I personally agree with this report, the new proposed wording is better. OAuth 2.1 editors, please take note! — Justin > On Jun 22, 2021, at 8:01 PM, Benjamin Kaduk wrote: > > This looks correct to me; could the authors/WG please confirm? > > Thanks, > > Ben > > On Thu, Jun 17, 2021 at 12:

Re: [OAUTH-WG] RAR WGLC comment

I agree with this change, but with one caveat (already expressed in the PR) that an AS should be aware that clients can now send scope, resource, and authorization_details parameters together on a single request. It’s not up to RAR to define how all of those fit together, but an AS implementing

Re: [OAUTH-WG] DPoP and implicit/hybrid flows

I personally hope we don’t. JAR already gives us signed requests at the authorization endpoint, though the last piece would be binding the token. — Justin > On Jul 15, 2021, at 6:47 PM, Dmitry Telegin > wrote: > > Hi, > > The DPoP spec currently defines how to obtain a DPoP-bound token via

Re: [OAUTH-WG] DPoP and implicit/hybrid flows

t; > I don't know if people really care about FAL3, unfourtunatly the simple > solution of using token-binding seems quite dead in browsers. > > John B. > > > > > > On Fri, Jul 16, 2021, 12:29 PM Justin Richer <mailto:jric...@mit.edu>> w

Re: [OAUTH-WG] Call for adoption - OAuth Proof of Possession Tokens with HTTP Message Signatures

Needless to say, but as the author of both this draft and the draft that it would replace, I am in favor of adoption of this document. There are still a lot of open questions to answer — such as key introduction and management practices — and I think there is a lot of power in the intersection o

Re: [OAUTH-WG] DPoP 03 - introspection - token_type?

Yes, it should be. Good catch. -Justin From: OAuth [oauth-boun...@ietf.org] on behalf of Vladimir Dzhuvinov [vladi...@connect2id.com] Sent: Sunday, August 15, 2021 12:02 PM To: oauth@ietf.org Subject: [OAUTH-WG] DPoP 03 - introspection - token_type? The

<    1   2   3   4   5   6   7   8   9   10   >