Minute taker: Hannes Tschofenig
Side sessions of OAuth at
Roman mentioned that the JWT Response for OAuth Token Introspection is
waiting for completion of the security BCP.
Discussion about reviewing the comments on the security BCP during the
side meetings.
For the DPoP Roman wants to specifically talk about algorithm agility.
The DPoP draft also has 6 authors and this needs to be mentioned in the
write-up (with a justification).
Aaron talks about the changes since the last IETF meeting and the
planned changes. The draft open issues can be found at
https://github.com/aaronpk/oauth-v2-1/issues.
Aaron suggests to add a section with CORS recommendations to the draft.
Daryl Miller: In the world of WASM does this also apply?
Aaron: I think we should not mention JavaScript
BrianC: Agree with the recommendations but requires background
information.
Mike: Asking what the specific language is we should be using.
Should this parameter be required at the token endpoint?
Mike: I suspect some code is going to break because the parameter is
required to be there for backwards compatibility reasons. I would be
fine with a note saying that this parameter is redundant when PKCE is
used.
Aaron: If OAuth 2.1 is used then there is always PKCE.
+1 from George
Aaron: If an AS follows best current practices then it should already
support the OAuth 2.1 functionality and the absence of the redirect_uri
parameter does not cause any problems.
Daniel: We should make sure that we are not introducing a security BCP
and OAuth 2.1 incompatibility.
Filip Skokan: If the purpose of OAuth 2.1 is to take 2.0 and to apply
all the BCPs then we should not omit this parameter.
Aaron: The question is whether an OAuth 2.1 client can interact with an
OAuth 2.0 AS that has all the BCP applied.
Filip: If there is a discovery service then we can do this.
Aaron: I think there is nothing else like this yet, things where 2.1 is
describing things that are not in the BCP. So if there are other things,
then it could make sense to use a discovery flag. I don't think there
are anything else like this yet but it is worth double-checking.
Justin: If we do option 2, we don't need discovery, because regardless
what the client does the AS will do the right thing if it's a 2.1 AS.
Aaron: That works great for 2.0 and 2.1 client talking to a 2.1 AS. But
that doesn't work for a 2.1 client talking to an OAuth 2.0 AS. So that's
the only one that breaks and if we're okay with that it's fine.
Rifaat: Are people comfortable with that? I see nods.
Brian: Don't see problems with approach #2.
Aaron: There is only a problem when a OAuth 2.0 client talks to an Oauth
2.1 AS.
Brian: That's OK for me.
Way forward: AS should accept and verify the redirect_uri if present,
but not require it. optionally allow clients to send it (see item 2 on
slide 8)
Rifaat: And make sure that the one breaking change is documented.
Filip: Personally I'm not okay with it breaking but if the consensus is
that we're okay if it's documented then sure. But I'm not sure that
should be the outcome unless there's discovery.
Aaron: My gut feeling is that it's okay, clients are less likely to
update unless they need to. So if they want to update, and they update
to what's called a 2.1 client, they won't be expecting it to work with a
2.0 server anyway, since there will be other things that break anyway
since 2.0 is a broad definition anyway. It feels like this is the okay
way to have it break. Let's also revisit this decision after I make the
list of other breaking changes from 2.0. So if it ends up being the only
breaking change for that combination of roles then we can revisit this
discussion.
Aaron talks about the changes since the last IETF meeting, particularly
the architectural patterns.
Aaron is soliciting feedback on the architectural patterns saying that
there are different ways to design the implementions. There are
different drawbacks with the present techniques and none of them is
good.
Aaron: Action item - Capture the recommendation of not using the Cookie
API as a storage API
Planned changes:
Aaron anticipates to get these changes in before the next IETF meeting.
Repo: https://github.com/oauth-wg/oauth-selective-disclosure-jwt
Daniel presents the updates since the last IETF meeting. Draft became a
WG item in the interim.
New draft uses improved terminology.
Digest derivation algorithm was introduced to refer to keyed and unkeyed
hash function.
Brian: The concept of digest derivation algorithms is problematic for
developers. The name, digest derivation algorithm, is not used in the
industry. The need for both approaches is questionable. The use of HMAC
is unspecified.
John: Agree with Brian. What you are doing is similar to KDF. You might
want to name it similarly. I would either remove it and say that you
have hashing algorithms or you have to add a lot more specifications.
Signature validation:
Brian raises a question about the holder binding and the complexity it
uses.
Daniel says that this is discussed later.
Tony: Does the holder binding also do device binding also?
Daniel: Yes, it can be.
Tony: I didn't see any text. We need to add text explaining his.
Daniel talks about the problems with the transfer of JSON and the use of
hasing. It is possible that the JSON is modified along the way from the
issuer to the verifier.
Hannes believes that canonicalization is unavoidable.
Daniel disagrees.
Daniel uses a different approach by changing the JSON into a byte string
with the assumption that the byte string is not modifed -- only the
JSON.
Justin: JSON strings have the ability to use unicode-encoded characters.
You have to be more precise. For example, inside JSON strings you are
allowed to replace forward with backwards characters. This works until
it does not. Look at RFC 8785 - JSON Canonicalization Scheme (JCS).
Daniel does not see the problem and believes that when you call JSON
encode and then JSON decode you get the same data.
Justin: You have to be precise when you assume to fetch and use the
data.
Justin: I am not against the approach but you need to be precise.
Orie: What you are doing is canonicalization.
Mike: I think you are doing hardening the JSON against modifications.
Yaron: Maybe you can change the claim names and the cardinality. A
well-defined claim document that is robust from a security point of
view.
Daniel: I am not sure whether this helps.
5 implementations and interoperability testing envisioned.
Brian provided background for the draft and also walked the group
through the changes of the draft versions.
Daryl: If you add a new parameter into the www-authorize HTTP header
field. Have you looked into the structured header fields work of the
HTTP working group?
Brian: I have to look into it. The space-delimited field is in the value
of the field.
Jaimandeep Singh: Do we want to include the other parameters as well,
like client authentication parameters?
Brian: It is beyond the scope of this document or not applicable.
Next step: Waiting for shepherd write-up.
The draft is about pop-up authentication.
Assumption: OAuth requires client to know who they are going to talk to.
Aaron: What we don't have is where the AS is? Define location of the AS
at the resource server.
Armando Faz-Hernandez: We are working on an option in the HTTP header
working group. (In privacy pass working group)
David Waite: There was an IETF OAuth draft to use the link header to
advertise the AS.
Filip Skokan: The presentation did not clarify who is driving the
interaction. If it is the user agent then it is limited to the web use
case.
Benjamin: This draft is expected to also work with a CLI application.
John: This is an interesting idea that needs to be explored. The error
from the RS returned what scopes were required but we didn't provide
information about what AS to use. There were security concerns. If we
change the model, we have to do a deep security review. Nat wrote a
draft about it. There are also a bunch of things in browsers that allow
WebViews that may be in conflict with how browsers work (such as
proof-of-possession tokens). It is definitely worth thinking about.
Minute taker: Hannes Tschofenig
Rifaat goes through his slides.
Yaron: Over time there have been multiple different semantics for
different tokens. Maybe it is good to express it explicit in the token
what the semantic is. Not necessarily to standardize it but to include
information in the token since it is signed.
Rifaat: give me an example.
Yaron: This is use case specific. For example, you shouldn't
Brian: I haven't worked a lot in this field but you have an extra
parameter. The idea behind the token exchange was to use the token type
to use rather than using additional parameters.
Robin Wilton: Regarding the repurposing one claim from one area to
another area: Don't worry about the semantics.
? : You are wrapping the original token into the new token. You give the
recipient the full control over -- complete delegated.
Kelley Burgin: If you include a token from one AS into a token that is
issued by a different AS.
Rifaat: That's the idea.
Kelly: You have to validate both.
Rifaat: Yes.
Atul goes through his presentation (but had to skip a few slides).
Discussion about this topic will continue at the side meeting tomorrow.
Interested parties are encouraged to read the background material linked
in the slide deck and to join the side meeting tomorrow.
Pieter presents the slides.
Justin: This is really important work. The user interation is often
overlooked. Are we getting close to standardizing the UX? This would be
important for cross- and same-device situations
Pieter: The word standardized is the word. We want a very consistent
user experience. Strong guidance and turning the guidance into
requirements. I have low expectations standardizing the pixel.
Justin: There is an entire community of UX experts we want to reach out
to.
Rifaat: Which community is that?
Justin: CM lab is the first group that comes to my mind. The Internet 2
community comes to mind. A lot of them are in the research community.
Pieter: There are plenty of us here working with UX experts. We should
get them involved. We can use this document to anchor the discussion.
Justin: That's a good point. This is quite specific to have something to
work with.
Pieter: We could present this work and ask the researchers how to solve
these problems.
Joseph Heenan: I have read the document. I refer people to the document.
I think there is interest. I think we should opt it.
George Fletcher: Design pattern makes a lot of sense.
John Bradley: I think this is good work. A couple of observations: The
WebAuthN thing (formly known as CABLE/Hybrid) is a different thing. It
is a transport thing. It may confuse people
Pieter: I take the point. We establish proximity through this Hybrid
protocol.
John: It is more than proximity. You are not doing the OAuth flow. From
a protocol flow it is pretty different.
John: CIBA was cross device because it was through a call center. That's
the origin of it. It was never meant to be used via a QR code. But once
it started people used it for lots of things.
Pieter: These protocols get designed for specific use cases in mind but
then they are used for other context. They shouldn't have used the
protocol in that way. I appreciate that it is not a traditional device
authorization flow.
John: We need a way to describe it. I think it is useful but there are
some challenges for describing it.
Pieter: I want to leave it with the implementers that they have better
options but separating it from multiple device OAuth.
Aaron Parecki: This is important. I also agree that the UX side is worth
pursing. This is something that's been missing from other work we've
published, but interestingly the user experience has ended up coming out
similarly between different implementations of the authorization flow
and device flow, there are a lot of commonalities. This is often a
question asked when people go to build the authorization screen, what
should you put there and how should it work.
Kristina Yasuda: Great work. Regarding: "Don't use cross device flows on
single device flows.". I believe that the cross device flow can also be
used on single device flows in the protocols I am involved with. I think
an extra sentence in the document would be useful. People are doing this
today.
Pieter: It is in the next version.
Hannes: Are you aware of any IPRs on this document? I looked at the
document and no IPRs are filed at the moment.
Pieter: No, I am not aware of any.
Rifaat: We will do a call for adoption on the document.
Kristina describes a number of different approach for how client_ids
are assigned and used in IETF/OpenID specifications today.
Aaron Parecki: OAuth 2.1: Yes, the language got relaxed to say "issued
by a trusted third party". I would like to further relax it to "issued
by an outside party". The security BCP says that the OAuth client should
not influence their own client id. That's not the right recommendation.
The example use case I would like to bring up is the open web where
there is no trust chain available (Wordpress, for example, where blogs
are run independently and are edited using an app running on a phone.
The app on the phone does not know what all the Wordpress instances are
installed). There is precedent for client IDs as a URL since 2014. The
IndieAuth spec was published as a W3C Note, now at
https://indieauth.spec.indieweb.org/
Brian Campbell: What is client id used for? It is used as a record for
what authorization is granted for. That needs to be added. That's what
every authorization server does.
Darrel Miller: We have so many issues with developer experience. We have
a lot of concerns around garbage collection and the consent issue. When
someone attempts to get access and the user confirms that an app grants
consent to access information to the client id.
Justin Richer: Most of what is in the slide is about the registration
and not in the client id.
As a response to Brian, you do not need a client id to identify a row in
the database.
The dynamic registration spec was added to obtain a client id. There are
a number of cases where you do not need the client id. Today, if the
client id has to be there and if you do not utilize it things break.
Technically, you do not need the client id, however. The language in 2.1
is an improvement. I think we need to think about client registration.
Client id is used as a stand-in on the registration.
Kristina: I didn't want to use "registration" when the client brings its
own metadata.
Justin: I agree, registration is very narrowly defined in OAuth. So, it
may need to be defined more generically.
Tobias Looker: Strong support for his work. Have done some work myself
in this area. Much of the language on this client id language is
limiting. The ability for the client to have some identifier that is
assigned by some third party as well as self-assigned is important.
Associating a client id with meta-data is best described as
registration. It may be associated with some policy. (Missed some parts)
Looking for feedback on
https://datatracker.ietf.org/doc/html/draft-looker-oauth-client-discovery-01
John Bradley: There is a perception of the OpenID Foundation to require
a unique root. That's a wrong perception. There are an infinite number
of roots supported.
Kristina: I think this needs clarified.