IETF
oauth@jabber.ietf.org
Monday, July 25, 2022< ^ >
Meetecho has set the subject to: OAuth at IETF113
Room Configuration
Room Occupants

GMT+0
[05:34:12] zulipbot joins the room
[14:01:44] <zulipbot> (Jaimandeep Singh) will side channels also be available to attend online
[14:05:55] <zulipbot> (George Fletcher) Yes, they have links in the agenda for the side meetings
[14:08:31] <zulipbot> (George Fletcher) https://trac.ietf.org/trac/ietf/meeting/wiki/114sidemeetings
[14:18:49] kaduk@jabber.org/barnowl joins the room
[14:26:38] <zulipbot> (Justin Richer) additional foot-gun: parsing the internal JSON in the claim string.
[14:26:52] <zulipbot> (Justin Richer) (but that is fixable)
[14:27:05] <zulipbot> (Hirsch Singhal) re: SD-JWT - the example at the start had parts of the complex object street address redacted (everything but country), but the SVC has the entire street address claim in one value.  Is this using a snark-like partial hash?
[14:32:25] <zulipbot> (Justin Richer) JCS is made out of foot-guns :)
[14:37:19] <zulipbot> (Justin Richer) right -- why not just send the array?
[14:38:14] <zulipbot> (Benjamin Kaduk) Who had the question prior to Leif's?
[14:40:21] <zulipbot> (George Fletcher) I'm in favor of adoption
[14:40:34] <zulipbot> (Justin Richer) I"m not raising my hadn for support
[14:40:35] <zulipbot> (Nat Sakimura) I'm in favour as well
[14:41:40] <zulipbot> (Justin Richer) I don't think anyone's watching the chat
[14:41:53] <zulipbot> (George Fletcher) Maybe not :)
[14:42:06] <zulipbot> (Nat Sakimura) I am :-)
[14:42:19] <zulipbot> (Nat Sakimura) (well, from Tokyo)
[14:42:32] <zulipbot> (Jaimandeep Singh) No audio
[14:42:32] <zulipbot> (Justin Richer) I mean anyone in the room :)
[14:42:45] <zulipbot> (Nat Sakimura) :-)
[14:42:45] <zulipbot> (Filip Skokan) audio went silent
[14:42:45] <zulipbot> (George Fletcher) Yeah... me too
[14:42:58] <zulipbot> (Jonas Primbs) me too
[14:42:59] <zulipbot> (Jaimandeep Singh) no audio
[14:43:27] <zulipbot> (Lorenzo Miniero) Working on it
[14:43:27] <zulipbot> (Filip Skokan) its bck
[14:43:40] <zulipbot> (Jaimandeep Singh) okay now
[14:43:41] <zulipbot> (Jonas Primbs) still working
[14:50:43] <zulipbot> (Nat Sakimura) I share the sentiment with George.
[14:50:56] <zulipbot> (Nat Sakimura) (Re: PKCE v.s. state)
[14:51:58] <zulipbot> (Aaron Parecki) I think the issue is that PKCE was written in the context of mobile apps where the default is that each client is a separate instance, and that assumption isn't there in web server apps, so it needs to be explicitly spelled out
[14:53:03] <zulipbot> (George Fletcher) I agree. If we enhance PCKE in the context of web clients then we potentially can make this a replacement for state.
[14:53:16] <zulipbot> (Kristina Yasuda) JWP and SD-JWT do not exactly solve the same problems
[14:55:07] <zulipbot> (Kristina Yasuda) JWP is focusing on creating a JOSE based container that can be used with emerging advanced crypto. The range of problems tackled are unlinkability, predicates, holder binding and not just SD.
[14:55:35] <zulipbot> (Kristina Yasuda) While SD-JWT Focuses on extending existing implementation with proven crypto and focuses on SD
[14:55:48] <zulipbot> (Justin Richer) you MAY validate access tokens.
[14:56:01] <zulipbot> (Kristina Yasuda) The efforts are complimentary and not competing
[14:56:01] <zulipbot> (Nat Sakimura) Ouch Re:RFC6750 re token validation
[14:56:14] <zulipbot> (Hannes Tschofenig) (for the meeting minutes)
[14:57:21] <zulipbot> (Justin Richer) @hannes added
[14:57:48] <zulipbot> (Hannes Tschofenig) Thanks, Justin, for adding your comment on the microphone to the meeting minutes. Makes a lot of sense.
[14:58:28] <zulipbot> (Hannes Tschofenig) George, I failed to record your long question on the microphone. Could you add it to the meeting minutes?
[15:00:53] <zulipbot> (George Fletcher) Yes, though you got the main jist :)
[15:03:36] <zulipbot> (George Fletcher) @hannes done. Let me know if you'd like more detail
[15:12:54] <zulipbot> (Nat Sakimura) Multiple AA thing is actually in OIDC Core 1.0 as a use-case at least.
[15:13:33] <zulipbot> (George Fletcher) There is some support for this in the token exchange spec as well the "act" claim
[15:18:09] <zulipbot> (Hannes Tschofenig) Thanks, George
[15:18:46] <zulipbot> (George Fletcher) The Token Exchange spec also has aspects of this in the definition of the "act" claim. I suspect that authorization use cases may also need the embedding of other tokens. If the workgroup adopts this work, I recommend the workgroup look at authorization use cases as well as identity claim use cases.
[15:19:16] <zulipbot> (Nat Sakimura) +1
[15:20:33] kaduk@jabber.org/barnowl leaves the room
[15:25:49] <zulipbot> (George Fletcher) Doesn't OIDC define client_secret_jwt which could be used for a client_credentials token binding?
[15:27:29] <zulipbot> (George Fletcher) OIDC Core section 9
[15:28:00] <zulipbot> (Justin Richer) @george the token's not included in the assertion coverage there
[15:29:29] <zulipbot> (George Fletcher) no but it could be
[15:30:22] <zulipbot> (George Fletcher) actually... as long as the token issued from a client_credential grant contains the client_id you could use client_secret_jwt to protect the binding
[15:30:35] <zulipbot> (Joseph Heenan) you can use dpop with client credentials grant, the issue is really the use of client_secret_basic/post client authentication when private_key_jwt gives you almost the same semantics as DPoP would.
[15:36:33] <zulipbot> (Hirsch Singhal) ^^ Yup, the mechanics are there, so the ask is mostly - [how] do you bind the token to the private_key_jwt? Should the same credential (long-lived registered key) be used to protect ephemeral tokens, or should there be a matching ephemeral key used?
Happy to spend time in a side session on this to plan concrete next steps
[15:43:47] <zulipbot> (George Fletcher) In regards to tokens crossing AS domains, I've implemented such a solution back in the days of AIM. It used Option-1
[15:44:00] <zulipbot> (Benjamin Kaduk) I'm a little curious if Atul has a specific definition of "RPC" in mind here
[15:45:16] <zulipbot> (Benjamin Kaduk) (since, e.g., I know a bunch of people for whom "RPC" means "Sun RPC", which seems to be not-this)
[15:45:17] <zulipbot> (George Fletcher) +1
[15:45:56] <zulipbot> (Justin Richer) I'm understanding it as "an API with a bunch of related calls in a row and/or some kind of statefulness" ... maybe?
[15:49:20] <zulipbot> (George Fletcher) I think there are many different aspects being brought up here... there are some references that might be helpful.
[15:49:21] <zulipbot> (George Fletcher) https://netflixtechblog.com/edge-authentication-and-token-agnostic-identity-propagation-514e47e0b602
[15:49:33] <zulipbot> (Benjamin Kaduk) I'm definitely hearing several intertwined topics as well.
[15:49:34] <zulipbot> (George Fletcher) https://identiverse.gallery.video/detail/videos/standards/video/6185213758001/transaction-tokens:-solving-the-external-internal-authorization-problem?autoStart=true
[15:49:54] <zulipbot> (George Fletcher) That last one was my presentation but it has aspects that relate
[15:51:33] <zulipbot> (Aaron Parecki) It also sounds like these "possible solutions" on the slides are also things already in a handful of security recommendations across a few docs
[15:52:08] <zulipbot> (George Fletcher) +1
[15:59:27] <zulipbot> (Benjamin Kaduk) In the Kerberos world, Microsoft's "services for user" (SFU) extensions (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94) include a concept of "constrained delegation" ("s4u2proxy"), where there's a privileged service that's allowed to act on behalf of certain (possibly all) users, but it has to specifically go and talk to the KDC each time it does so.  The KDC can apply a very flexible policy when deciding whether to issue that ticket, including requiring some evidence that the user being impersonated is actually making some request of the proxy service.
[15:59:40] <zulipbot> (Nat Sakimura) Thanks