IETF118 - OAuth WG Agenda

Tuesday (60 min)

Chairs update – Rifaat Shekh-Yusef/Hannes Tschofenig (15 min)

Rifaat remembers Vittorio.

Rifaat encourages the OAuth working group to provide feedback to the
Nomcom (https://datatracker.ietf.org/nomcom/2023/feedback/).

Rifaat notes that the bi-weekly OAuth Office Hour meeting invitations
might be out of date and that it be best if people removed their
possibly stale invitations from their calendars and downloaded new ones.

Two new documents published as RFCs, namely

Security BCP pushed to the IESG.

New documents adopted:

Charter discussion (30 min)

Yaron and Hannes briefly summarized the WIME and the SPICE BOFs

Rifaat says that the new documents are already in scope of the charter.

Justin: What is the reach of this group? What is the identity of this
working group?
We are not just doing extensions to OAuth. SD-JWT is not an extension to
OAuth.

Mike: OAuth WG is doing good work and I don't think there is need for a
course correction.
We have well-informed discussions about newly proposed work. I am happy
of where we are.

Brian: Since JWT was developed in this group I see SD-JWT as an
extension of the JWT. I would like to continue the work here.

Rifaat: Do you see a need update the charter?

Brian: I don't know. I also haven't read the charter recently.

Orie: It is web authorization: the web is more than HTTP and the web is
more than JOSE.
I agree with Brian. The work done here is excellent. No reason to move
the work anyway.
But: you also need to think about attracting people. Where do you send
the people when they work on CBOR-based extensions?

Rifaat: What is your proposal for the re-chartering?

Orie: If people bring CWT Status Lists here, would you send them to ACE?

Rohan: It's not clear to me why JWT was done in OAuth and not JOSE, same
as CWT in ACE.

Hannes: JWT was done here because it was a clear gap in the Oauth
protocol with the token format not described.
CWT was in ACE where HTTP was replaced with COAP, JWT was shrunk and
replaced with CBOR. Was that a good idea? Not sure.

Richard: There is a logical demarc point that was reached. With the
SPICE BOF there is a reason to move work over there.

Manu: I was looking for a group doing authentication. We have been
working on confidential computing. Is this the right place? Where can we
go to do this work?

Rifaat: OAuth works on authorization - not authentication. Maybe
SECDISPATCH is the right place.

Mike: Often decisions are the result of the people involved in making
the decisions. I am OK with all the outcomes.

Brian: ...

Pieter: It is important to have the right people involved in doing the
work. We have the right people here doing the work.

Roman: I don't know how to use the feedback. People want to continue

I would some of the things a bit more first order.

Justin: We don't need to make decisions in the same way as we did in the
past. Should we put JWT in the charter? "yes" Same for "SD-JWT". We
should also be careful that we are so widely welcoming so that it ends
up in this working group.
We need to be careful that it doesn't just become like a bluc of us
doing these things because we are interested in it.

Paul: In an ideal world, SD-JWT and Status Lists belong to SPICE. W ant
to issue government credentials in eIDAS and we need to consider the
urgency. The eIDAS is highly volatile and if we pull these specs out of
OAuth into something new then this appears to be dangerous. The time for
doing so is not right.

Summary from Rifaat: The documents should stay here. Nobody is arguing
that to move them somewhere. There is room for improvements of the OAuth
charter.

Orie: I want to echo what Paul said: "this group has a reputation".
People will send messages for review to the OAuth list. You need to
update the charter to reflect the scope of the group.

SD-JWT – Kristina Yasuda/Daniel Fett – (15 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

Daniel goes through the changes in the draft. Neil had comments about
cryptography.
More issues on the issue tracker.

Nine implementations available today.

Rohan: I can provide an example of a attack that can be mitigated In
MIMI we have an architecture with multiple hops. The local provider
could copy disclosures as the message passes by and include them
elsewhere.

Orie: There may be an agility issue with the hash algorithm. How do you
prevent people from having to implement multiple hash algorithm.

Daniel: We haven't decided about this yet. This is an open issue.

Orie: I have an idea. You lock it to the same scheme that the issuer
committed to.

Brian: This is what is says now.

Richard: I think Brian is right. I am fairly new to this draft. This is
getting pretty good. I am concerned about the key binding because it is
an ortonogonal thing. It seems useful to be without the key binding. I
would suggest to move this out. Has there been any formal modelling on
the key binding?

Daniel: The key binding is extremly simple: it is a signed JWT. It is
good to have it in there. It is closely connected to the use case for
selective disclosure. It is also relatively simple. If you move it into
a separate spec, there is not much to specify. I am wondering whether
the mechanism is not too simple. Having done a lot of formal analysis, I
think the analysis would be extremely boring because there is not much
to analyse.

Tristan: We ran into a few issues with the implementation with the more
complex constructions (like recursive JWTs). We got feedback from the
list but the draft would benefit from clarifications. Where should we
send those comments?

Daniel: I believe you have submitted a few clarifications to Github. If
you want, a PR is very welcome.

David Waite: I can see a profile for SD-JWT for access tokens. Key
binding would be an alternative for DPoP.

Wednesday (120 min)

Protected Resource Metadata – Mike Jones, Aaron Parecki (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/

Mike and Aaron go through their slide deck. Purpose of the spec is to
define an automated way to determine meta-data about the resource
server.

Two open issues:

  1. Should WWW-Authenticate return the Resource Identifier (RFC 8707) or
    the Resource Metadata URL?

George: Is there value to specify that the URI has to be a URL rather
than allowing a URL as well?

Justin: I would argue we should explore returning both under different
keys. If we do that we define what the semantics is.

Aaron argues for one approach. Return the URL to the metada.

Justin: Believes there is an argument for both as a logical resource
indicator may have specific meaning to the client. However, the
relatioship between the two needs to be defined.

Filip: We like that the resource indicators allow a URN. This is
probably not applicable here. Resolving the URI to a .well-known is a
problem. I think it should return the URL to the well-known document.
What resource to use would be in this document. Returning a URI should
be allowed at all.

Brian: The Resource Indicator allows a URI but it does not mean that it
needs to be used here. We can constrain it. Clients are not the only
entities that are doing the discovery. The well-known path construction
runs counter to what the recommendations are. I am worried about the
future way of progressing the draft.

Mike: You pointed out that others would also use this discovery. We
updated the draft. The server can also use this mechanism.

Regarding the well-known, we have made an update to the draft. I don't
want to repeat the experience with AS meta-data draft. Mark's argument
is that the Web security model is based on the web origin model.

Roman: We could ask the HTTP directorate for an early review if we want
to avoid suprise.

Neil Jenkins: This work is interesting to us. Having a document that
allows this client registration/discovery is important. The URL would be
a lot easier. I cannot see what scope I need. This is also important.

Mike: WWW-Authenticate can return a scope that you need to perform an
authorization. We are not touching this building block.

Aaron: We should mention this in the draft. The scope problem is a hard
problem because you need to have some information agreed to get this to
work.

Dimitri: The solid project uses a similar approach. Instead of the level
of the indirection, it links to the AS server directly.

Aaron: We use this approach initially. I cannot remember the exact
arguments. We agreed to point to the metadata, which points to the AS.
What happens if a request to example.com returns a pointer to a
meta-data from a completely different domain. At a minimum I would
expect the meta-data to point back to the resource. This is currently an
open issue.

Mike: We take a pass at returning the meta-data link diretly. Then, we
see how it looks like and then we take it from there.

Justin: Can you be more precise?

Mike: I would put the resource indicator in the meta-data directly. And
return the meta-data URL.

SD-JWT-based Verifiable Credentials (SD-JWT VC) – Oliver Terbu, Daniel Fett (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/

Oliver and Daniel go through the slides.

Slide about obtaining the verification key.

Brian: Do we really need to bring DIDs into the spec in a normative way?

Daniel: Yes, we need.

Brian: No, you don't.

Richard agrees with Brian.

Daniel believes otherwise. Describing a way to obtain the issuer's
verification key.

Brian: I want to push back on the DID.

Richard: Saying "did" means "we use a protocol". There are so many of
them.

Discussion will continue on the list.

Daniel mentions that there is a discussion in Github on the draft.

Richard: You may run into problems because if the only authorized usage
is TLS server authentication.
You could split the difference in the format of the credential based on
discovery.

Kristina: There are a punch of people implementing DID web with this
method and I do not want to shy them away. Specifying to use DID web
would be useful.

Attestation-Based Client Authentication – Paul Bastian (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/

Paul goes through the slides. The motivator is coming from the eIDAS
ecosystem.

Justin: This smells a lot like dynamic client registration. This is
directly applicable to other use cases.

Paul: I am not an OAuth expert. There is some overlap to dynamic client
registrations.

Tobias: I wanted to say that we call it the client backend.

Justin: Yes, this feels a bit more than being part of client
registration.

Tobias: How the client registers to the AS is outside the scope.

Filip: There was a use case slide and I want to say that this has to
work as a general mechanism. The reltionship between the key used by the
AS to verify the key needs to be specified (pre-registration, or
meta-data).

Aaron: Client attestation is not the same as client authentication. I
would like to do both. I want to use this mechanism also in other
endpoints like Dynamic Client Registration, PAR, etc.

Kristina: ... missed it ...

George: Agrees with what Aaron said. Attestation is different from
authentication. I would like to say that there are many places where
this could be used.

Ben Bucks: I work on Thunderbird. How can this be abused to prevent the
use of Thunderbird by specific some servers.

Browser-Based Apps - Aaron Parecki (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/

Aaron goes through his slides. Recommendations for developers building
apps that run in browser-based apps.

The document now starts with a description of the threats related to the
different deployment scenarios. The architectural patterns are now able
to reference which threats they do and do not protect against. It is
supposed to be more readable.

Rifaat: Are we ready for a WGLC?

Aaron: I believe we are ready (even though many have not read the latest
draft).

Justin: I have not yet read the latest version of the document. Does
this doc have considerations for storage of keys bound to access tokens?

Aaron: There is a section about the web crypto API and that the storage
of those keys are not necessarily hardware bound and may be stored on
the filesystem of the device.

Neil Jenkins: I am trying to find the DPoP references to see how the
secrets are stored.

Philippe: There is a section that briefly combines the use of DPoP. Even
with DPoP enabled it does not necessarily solve the problem because the
attacker can mount other attacks.

Aaron: The subject heading is called "sender-constrained tokens" and not
DPoP. There may be value in adding a section higher up in the doc to
show which attacks it helps mitigate and which is doesn't.

Justin: I would like that. The storage of keys is another deployment
pattern rather than just a security consideration. I would suggest to
"bubble up" this sec

Reviewers: Justin, Filip, and Andy Barlow volunteered.

Philippe: Justin, please review the draft and tell us again whether the
storage of keys needs to be a separate pattern.

Aaron: I am not sure where to "slot in" DPoP because it is not a silver
bullet because it does not solve all problems.

Cross-Device Flows – Pieter Kasselman (15 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/

Pieter goes through his slides.

There are three open issues. Daniel will re-write the formal analysis
section (in December).

Tony: Why are we adding a reference to the ISO mDL document? Which
document are you talking about?

Daniel: We need to think about it.

Kristina: If we talk about mDL we need to talk the entire VC space.

Daniel: We should talk about places where cross-device flows are used.

Reviewers: Tony, Andy

OAuth Status List - Paul Bastian (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/

Paul goes through the slides.

Leif: Scalability - numbers may be conservative. Some use cases have 20%
revocation. Integration with the token should have some algorithm
agility. Only one way of dealing with status lists. There should be a
way of improving the mechanisms when a better mechanisms is defined.

Paul: Agree with need for some updatability.

Justin: .. missed comments ..

Paul: URI should not contain the index and that will destroy the desired
privacy features

Aaron: Lot of applications of this in OAuth for tokens that are not
related to VCs. For example JWT Access Tokens. RS could cache the status
list and get the performance benefit.

Tobias: Trying to generally represent this as a generic token.

Aaron: Since OAuth has a JWT Access token and this work is in OAuth,
there should be a mention.

Hannes: Should reference the work in the W3C and also the reference to
"Let's revoke". Also it would be good to use the CWT-based status list
version instead of the JWT-based version since it is smaller in size
(particularly the Base64)

Yaron: Not a fan of CBOR but size would be valuable here. Are we
competing with W3C on the solution?

George: You need to describe under what conditions to use which
revocation mechanism.

David: Also seen much higher revocation rates (e.g. HR person attribute
change causes VC to be invalidated and reissued). Agrees with the
arguments regarding doing the work in the IETF (instead of doing it in
the W3C).

Oliver: If we want to support addition methods in the future, we can
define extensions.

Friday

Note-taking: Kristina

Transaction Tokens – George Fletcher (20 min)

https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/

Will take to the list and confirm as a final decision.

Identity Chaining – Pieter Kasselman (20 min)

https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/

Q&A

Will take to the ML to confirm.

The Use of Attestation in DCR – Ned Smith (20 min)

https://datatracker.ietf.org/doc/draft-tschofenig-oauth-attested-dclient-reg/

Q&A

First-Party Native Applications - Aaron Parecki (20 min)

https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/

Q&A

OAuth Global Token Revocation - Aaron Parecki (20 min)

https://datatracker.ietf.org/doc/draft-parecki-oauth-global-token-revocation/

Thank you all!