Henk: Brian is right (referring to 'Why not DIDs slide')
Mike Jones: DIDs are not currently referenced from specification (Brian:
correct) - let's keep it that way
Andy Barlow: I agree, including this would make it more complex and
confusing
Leif: Using x509 is perfectly good. You could profile the spec if you
want to include your own trust framework. It's not really a limitation,
e.g., using ACME to issue short-lived certs
Nat (via Rifaat): Also agree
Joseph: Gabe put some comments on an issue in the spec github about why
the did text was and it doesn't seem there's been much progress on any
of those. We shouldn't delay the main document, those issues can be
solved at the speed the DID community wants in a profile.
Rifaat: Does anyone disagree?
Hannes: Some of the community disagrees, we as chairs want to have a
good discussion
Steffen Schwalm: Section 3.5 is same justification, you could achieve
the same as shown on the slide whilst keeping the text in the spec.
Brian: Part of what I want to achieve is not burdening those reading the
spec with the cognitive overhead of something that is difficult to
understand, perhaps reputationaly fraut, whilst still allowing for it
amongst the communities that want it without attempting to describe the
(shall we say) undescribable. The text didn't work. The concerns on the
slide are legitimate slides of many people.
Steffen: Disagrees with Brian. 200 did methods, there is a
standardisation project in process in EU to standardise did methods,
this will be published next week.
Brian: perhaps that area where they are standardising did methods would
be an appropriate venue to define the extension we're talking about
here:
Marcus Sabadello: 5th time this was discussed. last time was removed
against wg consensus. PRs with deceptive titles. No consensus to remove
this.
Rifaat: Question to Marcus/Steffen - given you can extend and define
DIDs how you want, do you think this is an appropriate way to continue
and to not keep rehasing this issue for a long time without getting
anywhere?
Steffen: Section 3.5 was fully agreed, it should be kept until there is
consensus to remove it. We should not make a decision based on facts
that are not sufficient.
Marcus: Not sufficient. Support for DIDs was mandatory at one point.
Those of us that want to support DIDs need it. Why are there concerns
about a optional mechanism that people don't have to implement?
Oliver Terbu: One of the reasons the previous text was removed was
because it was not sufficient for interoperability. One of the ways to
make it interoperabile is to agree on which DID methods, how keys are
verifier, some DIDs have additional requirements. Multibase is another
layer of indefinite extensions by itself, lot of profiling work would
need to be done. This should not happen in OAuth WG because it's not an
OAuth concern and other more appropriate venues exist.
Tony: most people agree that it's not necessary
Hannes: Making changes that could be controversial should be discssed in
the WG before it happens, doing otherwise can cause delays.
Rifaat: Poll on this now, then we'll follow up on Mailing list.
Poll: "Should DID be included in this document?" 7 yes, 40 no, 9 no
opinion
Deb (AD): I think this result is clear. There's an option to write a
profile. This should option be taken up by the proponents.
Brian: This could happen in IETF, but could be anywhere. If there's any
feedback on changes that are needed in the main spec happy to take
those.
Gregor (chat): Three questions: (1) What Stage of the IETF process is
this document in? (2) What is the estimated Timeline? (3) Can it be
reasonably expected to not undergo major Changes?
Daniel (chat): We have a couple of open issues, but at this point are
not aware of anything that would lead to a breaking change in the core
of the document. We hope to close those soon and proceed to working
group last call.
his is always the working group's decision at the end of the day, of
course.
Deb (AD in chat): the draft is still in the working group (wglc is in
the future, possibly near future), there is no estimated timeline, since
the draft is still in the wg, changes can happen although this
particular draft is close to being ready.
Henk (chat): while there probably will not be overhauling normative
changes during WG contributions that find rough consensus, the IETF
process might introduce normative changes, e.g., during IETF ballot /
Last Call.
Deb (AD in chat): changes can happen during IETF Last Call and the
ballot by the IESG.
The timeline is extremely variable - months to years.
chairs noted that this draft is related to a security issue and should
be handled with some urgency by the WG
Hannes: Will have a call with authors to talk about how to progress
document, make sure expectations of WG & authoring style of IETF is
understood. We're keen to encourage new people to get involved and make
sure they can be effective.
Rifaat: May schedule an interim meeting on this and other topics before
Montreal.
Hannes: People need to read the papers before we can have a meaningful
discussion.
Aaron: Seems like a good idea to open this up, and we should be open to
including other topics in this doc, and keeping it open for a little
while to collect other updates. There isn't the same urgency as for the
'aud' updates.
Rifaat: First time this doc was discussed, no intention to rush it to
IESG.
Aaron: I sent a review in (on mailing list) a couple of hours ago.
Generally agree with the need for this. Supportive of most of the things
in it.
Brian: Worthwhile work, but I hope you're prepared for what you're
getting into, which is a larger set of updates including what Aaron
mentioned. Having followed some of the github issues there could be a
lot more work here than you realise you're signing up for. There's a doc
in JOSE deprecated none/old RSA, need to point to that or coordinate.
JWE/JWS confusion - there's a draft in JOSE (HPKE JOSE) that's doing
it's best to make that confusion even easier, there's an example that
shows claims as asym encrypted content like a JWT, doesn't say anywhere
that it's integrity protected, there's other problems about that, will
be discussed in JOSE. Current text on compression is a bit overreaching,
but it's okay in some cases, some implementers have dropped their
implementation because of that text which has caused interoperability
issues.
Yaron: This is a good reason for the WG to adopt the document.
Hannes: It's ironic that JWE/JWS confusion, it's not confusion about the
mechanism used, but you need to maintain information about what you
expect other party to provide - it's similar to alg aspect. We need to
level up and implementation needs to look back at what alg / context it
is intenting to use with the other party, it's a generic issue that
other libraries seem to have less of, not sure how we brought them into
JOSE/COSE.
Rifaat: Running out of time. Does any of this prevent us from adopting
the document?
Brian: No
Filip: The old JWT BCP is very much overlooked by implementors, anything
we can do to bring it to the front and have implementers read it is very
much welcome. Vulnerabilities mentioned here already fixed in many
implementations. Welcome the work contining and being adopted.
Brian: A few years back I did a talk on a conference on JWT
vulnerabilities and tried to look at all the critisms. People should
watch it: https://www.youtube.com/watch?v=IgKRGS6cQWw
Rifaat: We'll do a call for adoption on the mailing list
Brian: Asking in the room for WGLC on Identity and Authorization
Chaining Across Domains and WGAC on Identity Assertion Authorization
Grant
Rifaat: Anyone feel this doc is not ready for working group last call?
Rifaat: Will do WGLC on mailing list, obviously if there's lots of
comments we can continue work on it instead.
Topic switched to Aaron's related draft Identity Assertion Authorization
Grant:
Aaron: This is not an AI washing draft, it started before the AI hype
cycle. It is very directly enterprise related use case and it useful
without any AI tools involved in the process. AI was brought into the
story as AI makes the problem being solved way worse, that's the reason
for that example.
Pieter: Agree with Aaron. Also simplifies MCP integration & more it more
secure. Go read the draft. In favour of adoption.
Brian: Redirect uris are established in a registration request. They're
addressed here with a hard association with the document being pointed
too. Reliant on user understanding uris maybe, but you're giving the
user some ability to attempt to understand. There are tradeoffs. Some of
these ways allow concerns to be mitigated through other processes.
Leif: One point that jumps out at me is the trust management.
Brian: There's two docs here. The client id metadata one is a different
document, we're talking about the document that allows the client to
convey which mechanism is being used.
Leif: Federation has a lot of complexity to deal with this. Wouldn't it
be good to align with openid federation?
Brian: Federation is one of the mechanisms that can be used.
Rifaat: Will schedule an interim meeting to discuss this further before
doing a call for adoption, no time to discuss further today.
Jeff: Think this is something WG should work on
MikeJ: Automatic client registration is already defined in OpenID
Federation
Joseph: breaking it down into redirecting & non-redirecting flows isn't
quite right - flows that use PAR (and redirect) can fit into the way
non-redirecting flows are described
done
https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/
Rifaat: I started on shepherd writeup, might take a few more weeks due
to travel/conferences.
https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/
Pieter: No opinion on challenge endpoint currently. For DPoP
optimisation, has there been a security analysis done on reusing a proof
meant for one thing in a different context?
Tobias: One security benefit is that using the client attestation you
can effectively attest the dpop key used to bind the access token.
Brian: I don't think there's anything to worry about when using the same
kind to send a message to the same entity. This is nice optimisation
from performance and efficiency and reducing the number of signed
objects going over the wire. I'm in favour of the optimisation. I came
up with the idea before the challenge endpoint, but I'm in favour of the
challenge endpoint.
Brian: Do we talk about the ability to receive a dpop nonce from the new
challenge endpoint, that could be a nice optimisation, technically
already allowed probably but would be nice to mention it?
Christian: Makes sense to mention that in this draft.
Hannes: Was your security observation the result of a security analysis?
Brian: No, it was a gut feeling. I'm pretty comfortable with it.
Filip: Challenge endpoint works way better than what was there before. I
did an experimental implementation and to put the dpop nonce into the
challenge endpoint response was naturally a think I did. There's an open
issue about adding some text to explicitly mention that is something
that can/should be done.
Filip: On the optimisation, important to realise that this spec is
useful even when dpop is not being used, and dpop & attestations may be
handled in very different parts of client code, it may be difficult for
client to know if dpop will be used when using attestation (or vice
versa).
Brian: That's okay. If they don't use it they don't use it.
Filip: AS needs to be sure that when it's using this mechanism that it
applies same policies to dpop nonce as it would to attestation
challenge, so that same freshness etc properties are achieved.
Filip: Draft talks about usage of attestation at resource servers, but
only 3 times and doesn't really explain it. Should either expand the
text about this or get rid of this text.
Christian: Good point re: resource server. Would be good to get feedback
on if people want to use this at resource server?
Aaron: I think there is value in being able to use this at resource
servers. If there's a http resource proxy validating the attestations
then application validating dpop proof, then it might not be possible to
combine them. If that can be handled then the optimisation makes sense.
Yaron Zehavi: I have a use case that optimisation violates. Using draft
for securing web sessions / native app instances. DPoP & client
attestations are handled at different levels.
Rifaat: can we get volunteers to review?
Yaron, Brian, Filip, Pieter, David, Andy, Tim(in chat) all volunteered.
https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/
Yaron Sheffer: If everyone is bumping into the same issue maybe we
should go back to the HTTP band with the request to have a new
structured header that would fix our need? (in relation to issue #176)
Pieter: Reasonable idea but no need to have this specification blocked
behind doing so.
Justin: Structured fields were designed to add parseable structure to
values not already known to be parseable. We already have a parseable
value. For things like this, yeah it might be nice to have some to
indicate this is a compact jwt, it's not going to be a structured
header. Keep it as an unstructured field.
Dmitry Telegin: Spec already mentions SPIFFE in a couple of places. Does
automatic client registration SPIFFE document automatically apply to
this document?
Pieter: It could. If you have a SPIFFE credential you can use it to
authenticate the client, that was the intent. Nothing about the
registration discussion needs to become blocking here, we can keep them
separate.
Rifaat: Does anyone have a problem with starting WGLC? (no one speaks
up.) Seems reasonable, we'll do it.
https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-spiffe-client-auth/
Dmitry: RFC7523 requires 'iss', when we are profiling a spec is it okay
to remove a required field like 'iss'? It seems difficult for existing
implementations.
Arndt: Spiffe doesn't carry "iss" by default, as iss can define where
keys come from, and spiffe has a separate mechanism for key
distribution, e.g. SPIFFE trust bundle endpoint. We would not want
implementers to use the "iss" claim. Whether we do require it is up to
us. Dmitry could you create an issue?
Joe Salowey: Not looked through draft yet. How is audience handled? With
SPIFFE can you get jwts with a specific aud?
Arndt: Yes. Will follow RFC7523/7523bis. But will basically be
authorisation server.
Jeff: Not sure one single draft should cover both building on top of RFC
7523 & 8705. Two drafts might be better.
Arndt: Generally flexible about this. But a lot of the mechanisms are
more of less than same between the two profiles. If WG wants it split
out we could do it.
Rifaat: Looks like there's interest, but lets give people a chance to
review it before asking for adoption.
https://datatracker.ietf.org/doc/draft-watson-oauth-refresh-token-expiration/
Brian: I appreciate the value in the underlying ideas. Consent is a
thing in a lot of implementations, but it doesn't appear in the base
specifications. I struggle with backporting in a concept that doesn't
normatively exist. Although I haven't read the draft. But the
implications for the wider community/implementations make me nervous.
Refresh token rotation & expiration seems
Brian: Don't do anything with <>_expires_at, especially not adding an
expires_at for the access token (in addition to the existing
expires_in).
Hannes: Can you expand on your concerns re: consent? It's not an
unfamiliar concept in OAuth.
Brian: The word doesn't appear. "grant" is used.
Hannes: But everyone knows what it means, resource owner has to grant
something.
Brian: But when you talk about introducing normative items that mention
things that are currently only alluded to in the specs that becomes
problematic. Even grant is a fairly elusive concept in OAuth. A lot of
variation between how implementations handle grants. Mapping a specific
concept/name/implementation expectation could be tricky.
Nick: There is a section in 6749 which talks about this, could reference
that section.
Brian: Would encourage trying to reconcile the potential
disconnect/naming problem.
Justin: Agree with Brian that this draft would be defining a concept
that's fundamental to oauth but not yet defined. We've done similar
before though. Grant management from OIDF already deals with a lot of
these types of concepts. There is a lot of variation between
implementations, no consistent model of how this looks in the OAuth
world. Work like this would be pulling a thread that it doesn't
necesarily understand the entirety of the sweater it's attached to.
Nick: Maybe this should be preceded by a definitional document.
Aaron: The word 'consent' is not in 6749, but resource owners
authorisation/approval/grant is same concept and already there. Good
that this isn't creating a whole grant management API as that is fraut
with difficulty. This small targetted spec makes sense, do not try to
expand scope.
David Waite: Agree with not using term 'consent'. This seems to be
pretty focussed on client action based on AS policy. Those policies are
extremely diverse and not sure a client would be able to implement
without knowledge of specific server's behaviour.
Nick: I disagree.
Dick: "consent" is on page 59 of RFC6749.
(time ran out)
https://datatracker.ietf.org/doc/draft-zehavi-oauth-app2app-browserless/
Arndt: When you have this kind of federation time, the AS will often ask
the user for a choice of authorization servers - not an immediate 301.
How would you solve it?
Yaron: I don't have a solution yet. One option is to not support it,
draft will fallback to using the browser.
Nick Doty: Still thinking through the concept. One of the advantages of
using the browser is that we're teaching the user you do your
authentications on the origins that your expect. In the app2app case I'm
confused about what the user will see or know when they're doing the
authentication. By getting away from the browser you might be
undermining what we've been trying to teach the user.
Yaron: Mike gave me the same feedback. I put it into security
considerations. This only works when there's no interaction by the user
with the websites in the middle of the chain. So it's not violating the
OAuth native apps BCP, it's just following 302s, we're not collecting
the user's password at any point.
Will review: Arndt, Filip, Theo
https://github.com/identitymonk/draft-lombardo-oauth-client-extension-claims
Leif: Feels like this is similar to Vectors of Trust.
Filip: One of the great things Vittorio did when drafting JWT access
tokens was to compare existing JWT tokens from all the different vendors
and try to unify them. Of the 4 claims you are suggesting, 1 does seem
to be used in the wild. "gty" claim value is inconsistent across
existing implementations, so you should carefully consider the values &
claim name to be used.
https://github.com/identitymonk/draft-lombardo-oauth-step-up-authz-challenge-proto
Nick Watson: I support this draft. It's useful to be able to express a
wide variety of error conditions that can happen in real life servers
whether recoverable or not, it's important to be able to get back to the
AS to resolve it one way or the other.
https://www.ietf.org/archive/id/draft-richer-oauth-pushed-client-registration-00.html
Brian: I'm curious about this. This same concept keeps coming up.
Several different ideas in this area hanging about in this group, I'm
not sure if they can all coexist or if we should try to coalesce on one.
Justin: Interesting how many times client ids are being discussed even
this week and how some of the assumptions made 15 years ago don't fit
well in the new world.
Arndt: What resonates with me is the ephmeralness of the client ids in
this case as it prevents a whole load of issues that you would normally
have.
Justin: You need firm guard rails around when this is/isn't applicable.
Pieter: Yes, this is an important problem to go solve, we see it in a
lot of places. Different solutions are being proposed because there are
different angles. Maybe we need some kind of interim to see if there's
commanility between the three or four different proposals.
Leif: There's also the potential for this to be aligned with client
registration in OpenID Federation. It's good to avoid having lots of
overlapping specs.
https://datatracker.ietf.org/doc/draft-richer-oauth-tmb-claim/
Pieter: This is a problem that we've come across in other places as
well. I think we should do something about it. Options 2 or 3 (see
slides) seems best. If not, at least BCPs.
Hannes: What other places:
Pieter: This came up in Identity chaining draft, we described in
appendix. Also istio ambient (??) mode etc.
Justin: I've seen this in practice in an IoT type situation where you
have hardware issued keys on the devices coming from a trusterd CA, so
issuing a token to a hardware bound key is a valid thing to do but none
of our protocols allow that.
Arndt: I think it's a valid problem but I worry about it being used in
many bad ways.
Justin: I share your worry, which is why Option 0 is a bad idea.
Theodosios Dimitrakos: I have seen something similar in cross-enterprise
scenarios. I think combined options 2 & 3 would be best. I think it's
worth addressing.
Brian: Disagree with Pieter. 0 does have benefits, trying to do the work
might be a lot of work. But it is a problem. I worry about the
implications on all of us if we try to solve the problem. I slightly
prefer option 0 just due to the possibility of the work consuming us.
David: If we decide this is valid, 2 or 3 is better than 1, we need to
be able to indicate when this is happening. "presentation of this proof
of possession doesn't mean what you think it means" to guide people into
being explicit and applying policies. I'm not sure if this concept is
needed.
Rifaat: Let's start a thread on the mailing list to see what people want
to do with this.