Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

Two thumbs up! I would rather delay and get it right. Good things come to those who wait. But; I am the least experienced standard author or advisor. I am an idealist and am ok stating my opinion and moving on so others with more experience in this area can make the decisions. Aloha. - Jim

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

I have a draft from a coworker that defines a cookie response mode and cookie bearer token usage. It's something we've considered bringing to the working group but haven't actually proposed yet. Is this the kind of thing you're talking about? https://github.com/jaredhanson/draft-oauth-cookie-respo

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

I hear you Jim, but it is not so much rules, as expectations and expediency.. There may be significant debate on how to do the feature. You would not want to hold up the OAuth 2.1 document for that would you? There are other documents already in flight -- which other ones should OAuth 2.1 wait for

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

I politely encourage the rules to be bent and to integrate this basic but fundamental security control into the core standard. This is just basic security; we want as much basic security in the core of any standard. Dev’s now need to read 20 standards to get OAuth2 basics... and that’s a barrie

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

One of the constraints of the OAuth 2.1 document that aligned the WG was it would have no new features. I'd recommend a separate document for the cookie bearer token feature. ᐧ On Thu, Jul 30, 2020 at 12:15 PM Jim Manico wrote: > Yea to cookie configuration suggestions! > > I suggest SameSite=

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

Yea to cookie configuration suggestions! I suggest SameSite=LAX at least, which is actually the default behavior in chrome if you do not set the samesite value. LAX will not break links that originate from emails, STRICT will. Point being is that CSRF defense is easy. XSS defense is brutally ha

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

> > Cookie storage of tokens does leave one open to CSRF attacks so it's > certainly a trade-off. But CSRF is much easier to defense against that XSS > and cookies are a better choice if the specific risk of having tokens > stolen via XSS matters to your threat model. I would assume if we include

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

I haven't seen any OAuth drafts that talk about sending OAuth access tokens in HTTP cookies. OAuth 2.1 isn't supposed to add new features that don't already exist, but this sounds like a good candidate to develop as an OAuth extension. --- Aaron Parecki https://aaronparecki.com https://oauth2simpl

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

In a browser, HTTPOnly cookies are the *only* location where an access (or other) token can be stored in a way where it *cannot be stolen from XSS*. It's a very strong place to store tokens from a security point of view. Cookie storage of tokens does leave one open to CSRF attacks so it's cer

Re: [OAUTH-WG] Authorization Code Grant diagram Improvement OAuth 2.1 draft-ietf-oauth-v2-1

These numbers in the diagram correspond to the numbered steps in the paragraphs below the diagram. Perhaps using non-duplicated numbers would help, such as "1a" and "1b" instead of two instances of "1"? Although I'm not sure how that would work exactly because the "1/2/3" are really just a single a

[OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-bearer-tokens It seems recently more and more common to pass the access_token to some RS via a cookie, yet 7.2.1 says it defines two methods. I think we need some RFC2119 k

[OAUTH-WG] Authorization Code Grant diagram Improvement OAuth 2.1 draft-ietf-oauth-v2-1

https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-authorization-code-grant Can we avoid using (1, 2, 3) on the left side of the diagram to describe, I'm not even sure what they are supposed to represent, not to mention the RO in the diagram doesn't really provide value (for me) relevant t

[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-1-00.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 : The OAuth 2.1 Authorization Framework Authors : Dick Hardt Aaron Parecki

Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document

+1 On Thu, 16 Jul 2020 at 23:57, Vladimir Dzhuvinov wrote: > > +1 > > Vladimir > > On 15/07/2020 20:54, Dick Hardt wrote: > > +1 > > On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef > wrote: >> >> All, >> >> This is a call for adoption for the following OAuth 2.1 document as a WG >> documen

Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document

All, This concludes our call for adoption for this document. The WG has decided to adopt this draft as a WG document. *Authors,* Feel free to submit a WG version of the document. Regards, Rifaat On Fri, Jul 17, 2020 at 9:29 AM Nat Sakimura wrote: > +1 > > On Fri, Jul 17, 2020 at 3:57 PM V

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

Aaron, The “request_uri” comes from OIDC originally, and is redefined in JAR. The original idea was to have a URL that the AS/IdP would be able to fetch to get a Request Object from, which is why JAR used to have language about “it MUST be fetchable and resolve to a JWT” (or something like that