22 March 2021, 12:00pm EDT
Note taker: Dan Moore
Topic is OAuth 2.1
Daniel: does not think relaxing the single use of auth code requirement is a good idea. For example, if you have an attack where attacker can control part of auth request, or if attacker can see parts of token request, pkce info may be seen.
Single use requirement can be a major hurdle for attackers in above scenarios.
What happens if requirement is relaxed, what are the semantics.
Justin: agreed, still benefit in single use. Would be beneficial to clarify what 'single use' means. Most implementations are 'burn on first use'. Other options: 'remember for a few minutes'. Clarity needed.
Dick: 'Single use' implies it is never used again. What we mean is 'that code is only valid for one outstanding request'. Let's clarify for what we actually mean.
Filip: Definitely rephrase it. If replay comes in, we should mention you revoke all tokens from the original authorization code.
Aaron: there are servers in the wild that don't do this. What to do about them? Are they still non-compliant?
Torsten: Responding to Filip's point. Goal of 65 is to simplify implementor's life. If we want folks to revoke tokens after replay comes in, that complicates implementor's tasks. Think carefully about what happens after reply is detected.
Filip: I get Torsten's point. This might be better directed at Mike Jones to reflect what OIDC Certification Suite does.
Aaron: Allowing replay in the time window isn't any different than having it expire normally. Authorization codes short lived. Not different than relaxing single use.
Mike: Found that too many implementations of OIDC used time based rather than ACID consistency. Therefore, in test suite authorization code fails if used after 30 seconds. Hard limit not enforced in practice.
Daniel: Keep in mind we still allow cases where nonce can be used instead of pkce, consider that. Fears it will unneccsarily complicate the spec.
Aaron: Two sides: everyone agrees that security of single use is good. Other side: it's not practical. What to do?
Aaron: To improve this, be more specific about authorization codes aren't globally unique. Then, we can try to find more language to clarify for other cases.
Torsten: security bcp will be recommending use of
iss to prevent mixup attacks. Should we add to OAuth 2.1? No reference in spec right now. We only wanted to add mature elements to OAuth2.1, but this seems to be exception because of the hard work done by the BCP.
Aaron: Only recommended if clients use multiple ASes.
Mike: Understand the desire to include, but we should stay with the intent of the spec: documenting what people are actually doing. On dangerous ground when we start extending.
Torsten: Alternative is to let folks run into the mixup problem. We should provide correct solution, then document exceptions. Did with pkce and nonce, could do here.
Daniel: We have exceptions in the BCP if the
iss is delivered in the ID Token or via other means
Mike: I won't lose sleep, but think it should be in the security BCP.
Torsten: Idea of OAuth 2.1 is to get rid of the security BCP as something that implementors had to read.
Mike: I thought we were stapling together parts of OAuth2 that people used in practice.
Torsten: We can check back at the singapore meeting notes.
Dick: The goal was to include the BCP so someone wouldn't have to read another document to do the right thing.
Mike: In that case, makes sense, I didn't think we needed to incorporate BCP.
Dick: BCP will continue to evolve after OAuth 2.1 ships.
Dick: This will be a SHOULD, not a MUST.
Mike: wouldn't lose sleep over this approach.
iss parameter is the only solid protection against mixup, we really need this parameter.
Vittorio: add my support. Multi-issuer is under specified. As long as it is 'should' and the id_token is equivalent, I think it'll be useful.
Host: It seems there is support for this.
Aaron: Will change to require the
iss value to be provided.
Aaron: how do we approach these flows?
Current state: nothing in OAuth2.1 mentioning implicit. If using OIDC's id_token, no need for pkce.
Is that good enough, or do we need more?
Will people be confused by the omission of response_type token?
Aaron then listed the options in the slide.
Mike: Vittorio made a good point in a review. Security charactirisit of implicit/fragment differnt than form post response mode. No reason to deprecate the latter. Stay with no mention, but if you are, mention the differences.
Aaron: I hear you, but it still is handing it to the browser, rather than the token being retrieved in the back channel.
Daniel: form post doens't protect against replay.
Mike: Let's stay with no mention, focus on what we want people to do.
Jeff: Agree with Mike, not worth bringing up things outside of scope, esp w/r/t extenstions.
Vittorio: From lawyer perspective ok with not mentioning anything, people familiar with specs will know oidc can still use implicit. But he has customers and community members who use form post, and read spec, and say "I can't do implicit, what should I do"
He needs something in the spec: don't worry, the form post implicit case is fine. Would vote for encouraging OpenID to deprecate token containing types is good, but separate issues.
He would vote against #2 options
Torsten: thinks it would be better to have OIDC to take oppty to take a published position on response types (given the new OAuth spec).
Vittorio: in the spirit of "one doc to look at", seems weird to ask them to look at open id published position.
Dick: somebody implementing OIDC should read those docs. Doesn't make sense to have Oauth reference OIDC.
Vittorio: nonce is already referenced. I would like to avoid having the conversation about implicit being removed altogether. One line would be great.
Dick: You're not suggesting that someone is going to implement OIDC without reading the oidc docs?
Aaron: suggestion: would it solve Vittorio's issue to mention in the changes section that implicit for OIDC ok?
Vittorio: as long as it is in the document somewhere, that solves my problem.
Torsten: Can update in the changes section, document the response types removed, no longer recommended.
Aaron: would be happier if "leaving response type token doesn't affect other profiles" were in the changes section, rather than in the security section.
Dick: don't want to reference another spec. For sure don't want people to be confused about conflicts between OIDC and OAuth 2.1. Putting it in the differences might work.
Torsten: give it a crack and dicuss
Mike: I think that adding a sentence or two would be a path forward. Probably better than saying nothing for customers.
Host: 5 minutes left
Roberto: general question: newcomer, curious if you could consider latest http specification, cert validation. Please think about it. I filed some issues around TLS consideration with OAuth.
Host: generic comment
Roberto: in some parts "use TLS" other parts not mentioned, as a first time user it was very confusing.
Mike: In some sense referencing additional response types. We should make an affirmative statement that the registries specified in 6749 and 6750 still valid.
[... comment lost]
Torsten: would we need to create new registries??
Mike: another registry would defeat goal of compability with Oauth 2
Torsten: would need to augment
Mike: if we bifurcate registtyr, might as well call this oauth3.
Aaron: we could remove response type token from the registry. That would give the spec something to do with the registry.
Mike: We should confirm we are using the same registries.
Vittorio suggests one more interim for 2.1.
The OAuth 2.1 Authorization Framework
Presenter: Aaron Parecki
Slides: OAuth 2.1 Slides
IETF OAuth2.1 Draft
Client Intermediary Metadata – Aaron
Multi-Subject JWT – Rifaat
RAR – Torsten
Security BCP – Daniel
Identity Use Cases in Browser Catalog – Vittorio/George
TMI BFF – Vittorio/Brian