[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

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

h 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 >> https://aaronparecki.com >>

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 real

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] 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

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] Namespacing "type" in RAR

ma 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: > Stri

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

> 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

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>> wrote: &g

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

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-richer-tr

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

> 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:

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 >&

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

[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.

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

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,

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

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] 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

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

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

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] 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

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

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] 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

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

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] RFC 7592 - Client Update Request omitted fields

d be 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] 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] OAuth 2.1: dropping password grant

>>>>> @aaronpk >>>>> >>>>> >>>>> >>>>> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell >>>>> >>>> <mailto:40pingidentity@dmarc.ietf.org>> wrote: >>>>> Concur with the s

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

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, Justin Ri

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

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

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

> > > 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 exist the

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

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

u 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] [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

[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

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 stan

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

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

hey 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>>: >>> >>> +1 to

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 t

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

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

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

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

uest_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. > > > > V

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

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

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

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”. —

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

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] 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] JWT Secured Authorization Request (JAR) vs OIDC request object

rameters included in the request object." > which will bring about [Problem 3-1]. That is, how about adding a rule like > "if request parameters exist outside the request object, they must exist > inside the request object, too."? > > Any thoughts? > > B

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|

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,

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

I support adoption of PAR and have already implemented the draft specification. - Justin > On Dec 17, 2019, at 7:59 AM, Rifaat Shekh-Yusef wrote: > > All, > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests document. >

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 > wrote: > > With respect to the Pushed Authorization Requests (PAR) draft

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

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

Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

1. Normative MUST/REQUIRED is fine in a BCP. 2. This is not the definitive list, but instead the best list of things that we have at this time. There will be more attacks, and more mitigations for those attacks. — Justin > On Nov 6, 2019, at 3:16 PM, Jared Jennings wrote: > > Hi, > >

Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 106

I’d like to present a readout of the TXAuth BoF, which is happening earlier in the week. — Justin > On Oct 4, 2019, at 2:08 PM, IETF Meeting Session Request Tool > wrote: > > > > A new meeting session request has just been submitted by Hannes Tschofenig, a > Chair of the oauth working

Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)

that we all agree works and has these properties”. — Justin > On Oct 30, 2019, at 3:43 AM, Neil Madden wrote: > > Replies below. > >> On 29 Oct 2019, at 19:13, Justin Richer wrote: >> >> I would argue that making this standard would actually increase the >&

Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)

I would argue that making this standard would actually increase the likelihood of developers getting this right, as now instead of following some copy-pasted recipe for NGINX or Apache that they found on the web, they could turn on a standard setting that would take care of both stripping out

Re: [OAUTH-WG] [Txauth] Tx Auth BOF agenda items

The intended scope is to provide a transactional model for doing authorization delegation, not for authenticating a transaction itself. I can understand the confusion! Naming things is hard. — Justin > On Oct 28, 2019, at 1:55 PM, Kyle Rose wrote: > > On Mon, Oct 28, 2019 at 11:39 AM Dick

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

I also agree. Would it be possible to get this pushed to http or tls? It would be more appropriate there, and very helpful to have a general spec for this. — Justin On Oct 23, 2019, at 2:10 PM, Brian Campbell mailto:bcampbell=40pingidentity@dmarc.ietf.org>> wrote: I agree with Ben here

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

you’re dealing with without decrypting the object. I think that probably needs to be addressed in JAR. — Justin On Oct 10, 2019, at 12:59 PM, Justin Richer mailto:jric...@mit.edu>> wrote: Thanks for the response. My concern is that interpretation of the requirement to “authenticate the

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

ient authentication middleware in place already takes care of that. S pozdravem, Filip Skokan On Thu, 10 Oct 2019 at 03:13, Justin Richer mailto:jric...@mit.edu>> wrote: So in doing an implementation of this, I ran into this problem as well. Specifically, we need to know which client we’re dea

Re: [OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2?

They are in that registry as the “token endpoint response” error codes. RFC8628 adds new ones. I think that 6749 failed to put in the base ones. — Justin On Oct 10, 2019, at 5:15 AM, Ludwig Seitz mailto:ludwig.se...@ri.se>> wrote: Hello OAuth WG, while addressing some AD review comments on

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt

10/2/19 11:45 AM, Brian Campbell wrote: I guess we differ in our opinion of how remiss that would be. But given what you've got in there now, the more narrow point I was trying to make was to say that I don't think "data" is defined or explained well enough to be helpful. On Tue, Oct 1, 20

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

So in doing an implementation of this, I ran into this problem as well. Specifically, we need to know which client we’re dealing with to fully validate the encrypted request object as well as perform the authentication. Currently, things are a little underspecified, and part of that comes from

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

I stand with Ben’s contention that introspection should be about getting information :about: a token, and not about getting a new token. In fact, this was one of the core issues that I had with the draft as originally proposed. If there are problems with token exchange, they should be fixed

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

pot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D=zerocontent=432ca2fb-c1d5-411f-aa84-23542ebab7e1]ᐧ On Thu, Sep 26, 2019 at 2:24 PM Justin Richer mailto:jric...@mit.edu>> wrote: Yes, the request object is JWT-based, but the request URI is not. In other words, you can post a JWT but what yo

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt

data being requested from the resource" and I'm honestly having a hard time understanding what that actually means or how it would be used in practice. And I'm not sure roughly equating it to “what kind of thing I want” helped me understand any better. On Tue, Sep 24, 2019 at 5:34 PM

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

-based request objects. Aaron Parecki aaronparecki.com<http://aaronparecki.com> On Thu, Sep 26, 2019 at 6:49 PM Justin Richer wrote: Aaron, some comments inline. — Justin On Sep 26, 2019, at 8:30 AM, Aaron Parecki wrote: Hi Torsten, I'm very glad to see this draft, I think it'

[OAUTH-WG] Transactional Authorization: TXAuth Mailing List and BoF

Following up from the discussion in Montreal, we’ve created the non-working-group mailing list TXAuth to start discussion of transactional authorization work. Please join the list here: https://www.ietf.org/mailman/listinfo/txauth We’ve also proposed a BoF for Singapore. The details of the

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

Aaron, some comments inline. — Justin On Sep 26, 2019, at 8:30 AM, Aaron Parecki mailto:aa...@parecki.com>> wrote: Hi Torsten, I'm very glad to see this draft, I think it's definitely needed in this space. Here are some of my thoughts on the draft. "request_uri":

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt

d transaction oriented authorization requests much easier than with current OAuth 2.0. I???m happy that Justin Richer and Brian Campbell joined me as authors of this draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their v

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt

of the request with base64, as it is in JOSE, and doing so would make it one more step removed from easy developer understanding. -- Justin Richer Bespoke Engineering +1 (617) 564-3801 https://bspk.io/ > On Sep 24, 2019, at 1:45 PM, George Fletcher wrote: > > Just two questions... >

Re: [OAUTH-WG] Question regarding RFC 7592

ment of its registration to not be a resource operation, but a management API. [https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D=zerocontent=2f153226-16c8-47cf-917d-a04714e9a474]ᐧ On Mon, Sep 16, 2019 at 7:36 PM Justin Richer mailto:jric...@mit.edu>> wrote: I don’t se

Re: [OAUTH-WG] Question regarding RFC 7592

sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D=zerocontent=5c4bbc80-1f00-4351-9a9b-954805e3d560]ᐧ On Fri, Sep 13, 2019 at 12:08 PM Justin Richer mailto:jric...@mit.edu>> wrote: Travis has this correct — the “registration access token” is passed to the client for the express purpose of accessing the client ma

Re: [OAUTH-WG] Public client cloning

If the phone is compromised, it doesn’t matter if the client is public or confidential. In the latter case, an attacker could exfiltrate or capture the client’s own credentials and use them maliciously. — Justin On Sep 10, 2019, at 3:27 PM, Masakazu OHTSUKA mailto:o.masak...@gmail.com>>

Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05

>> wrote: +1 This feels like it has similar requirements and concerns as for SET and may be should leverage it to avoid confusion and inconsistencies down the road. Phil On Sep 4, 2019, at 12:49 PM, Justin Richer mailto:jric...@mit.edu>> wrote: As I’ve said in the p

Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05

As I’ve said in the past, I think there is and should be a clear difference between a JWT access token and a JWT-formatted response from any endpoint. It gets extra fuzzy here because the response from the endpoint represents the token being introspected. However, I think they are still two

Re: [OAUTH-WG] IETF Meetup for XYZ

FWIW: We are meeting in the main lobby outside of Centre-Ville. — Justin On Jul 24, 2019, at 7:41 PM, Justin Richer mailto:jric...@mit.edu>> wrote: Hi all, I was talking with Hannes, and we’d like to propose a dinner meetup tomorrow (Thursday) for anyone who wants to discuss XYZ i

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

ts. I would very much like to see that. native/web possibly in combination with token_endpoint_auth_method and the client being DCR or "static" is far from being enough to make a policy decision. S pozdravem, Filip Skokan On Thu, 25 Jul 2019 at 13:45, Justin Richer mailto:jric...

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

This raises an interesting question that I don’t think we’ve addressed yet: how to appropriately vary token lifetimes and access for different clients. Previously, an AS could see that a client was using the implicit flow and decide to limit token lifetimes or scopes based on that alone.

[OAUTH-WG] IETF Meetup for XYZ

Hi all, I was talking with Hannes, and we’d like to propose a dinner meetup tomorrow (Thursday) for anyone who wants to discuss XYZ in more detail while we’re here in Montreal. We’ll meet right after the ACE working group session and find a place nearby, so that some of us can get back in time

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

It would perhaps be better to phrase it as “don’t use OAuth in the JavaScript application directly” instead of “not entirely”. — Justin On Jul 23, 2019, at 12:14 AM, Leo Tohill mailto:leotoh...@gmail.com>> wrote: I didn't see the earlier discussion (do you have a date or title?) so apologies

Re: [OAUTH-WG] Transaction Authorization

or comparing and contrasting different approaches. One of my first comments is why the client is starting off making calls to the AS. There are times when the AS is not known for a given resource. Why not allow starting at resource? On Tue, Jul 9, 2019 at 12:48 PM Justin Richer mailto:jric...@mit

Re: [OAUTH-WG] Transaction Authorization

I get the desire to have multiple tokens, but the real cost is the explosion in complexity for every party in the system. This is especially true if you allow the client to specify a more fine-grained and structured resource target than a scope string, but even with a scope it’s really common

Re: [OAUTH-WG] Refresh tokens

I think it can be as simple as: SHOULD NOT use refresh tokens without client authentication or key proof of some kind. In other words, no bearer refresh tokens. — Justin On Jul 19, 2019, at 7:49 PM, Aaron Parecki mailto:aa...@parecki.com>> wrote: So what I'm hearing in this thread is

[OAUTH-WG] Transaction Authorization

I have requested time to present Transactional Authorization (the XYZ project) at the Montreal meeting in a couple weeks. Ahead of that, I’ve uploaded a new version of the spec: https://tools.ietf.org/html/draft-richer-transactional-authz-02 Additionally, I’ve updated the writeup and examples

Re: [OAUTH-WG] ID Token by Device Flow

Taka, My reading is that the device flow, like other OAuth flows, does not prohibit extension, including passing back identity assertions like the ID Token. Since it inherits the token response from core OAuth 2, the ID Token could be issued along side the access token just like in the

Re: [OAUTH-WG] OAuth WG Sessions in Montreal

I would like to discuss the Transactional Authorization (XYZ) draft. https://tools.ietf.org/html/draft-richer-transactional-authz-00 — Justin On May 27, 2019, at 5:03 PM, Rifaat Shekh-Yusef mailto:rifaat.i...@gmail.com>> wrote: All, Please, let us know if you have any topics that you would

Re: [OAUTH-WG] XYZ and Transactional OAuth

I’ve submitted my draft of XYZ as an ID: https://tools.ietf.org/html/draft-richer-transactional-authz-00 — Justin On May 6, 2019, at 3:43 PM, Justin Richer mailto:jric...@mit.edu>> wrote: In a vein related to Torsten’s recent thread and blog post, I’ve also been working on a proposal

Re: [OAUTH-WG] MTLS vs. DPOP

For what it’s worth, if we think of things a little bit differently, we can support both types of key presentation and possession proofs in parallel. My thinking was that in both the MTLS and DPoP cases, the client proves that it has access to a key and then uses that key with the RS in the

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

This is not an easy question to answer, as resource servers in OAuth have never really had a strong identity (or identifier) within the OAuth ecosystem. The Resource Identifiers draft [1] tries to address this somewhat. In practice, many resource servers are registered and stored as “clients”

<    1   2   3   4   5   6   7   8   9   >