Session Date/Time: 04 May 2026 17:00
Rifaat Shekh-Yusef: Hello, anybody on the bridge can hear me?
Emelia Smith: That works.
Rifaat Shekh-Yusef: Yes. Okay. Thank you. Thank you guys. Sorry. I don't know what's going on. I know what this is. Hold on. Okay. Sorry about that. Okay. We are on time though. While we're waiting, can I get a volunteer to take notes because unfortunately, Hannes is not here. Anybody can take notes for us? Be appreciated. Any volunteer? Thanks, Emelia. Appreciate that. Maybe can somebody else also help with that? Maybe two, because Emelia is not feeling well today, so it'd be great. Maybe Aaron, do you want to, can you please help with that? Oh, here's Max. Okay. Thank you. Yes, you do. Okay. Okay, and I have Christian here. Okay, perfect. Let's give people one more minute and then we'll get started.
Christian Bormann: Will you be sharing the slides?
Rifaat Shekh-Yusef: It's up to you. I can. You let me know.
Christian Bormann: Would work if you can share. That's fine.
Rifaat Shekh-Yusef: Sure, sure. Okay, I think we should get going here. Okay. Welcome everyone. I need to update this slide deck, it says September, October 25. Sorry about that. So it's, we are 26 already, just in case. So this is the Note Well. A reminder that Note Well applies here, so this governs everything that we do at IETF, including IPRs, behavior and contribution. So if you're not familiar with this, please get familiar with this. So we have today, we have discussion about attestation based client authentication, but we still have two more interims. The next one is next week to talk about [draft-ietf-oauth-refresh-token-expiration] and the third one in June 1st to talk about agentic AI and OAuth discussion. So we have a bunch of AI agent, agentic AI drafts and we want to have that discussion and see what, how do we want to fit that into the OAuth working group. So that's a discussion that we need to have in June 1st. So that's the agenda. Any comments, questions about this? Okay. If not, I'm going to share the slides, and Christian, I think I should be able to hand you the control. See if you can. Okay. Perfect. You're good to go.
Christian Bormann: All right. So this is the interim session on attestation based client authentication. It's the updates since IETF 124, since we were not able to present at the Shenzhen IETF 125. Let's see if I can... yes. So what we're talking about is on the datatracker, the updates in the version 08 [draft-ietf-oauth-attestation-based-client-auth-08]. And then we have an editors' draft that has a few more changes that we would like to discuss before we cut a new version. So what changed since IETF 124 is everything in version 08, which is a lot of the feedback that was discussed in that session and a lot of cleanup. So main focus of that version was basically to remove a lot of older things that didn't fit anymore properly, restructure the draft quite a bit to improve readability, and add a lot of clarifications. So that this is actually targeting, for example, not public clients, but confidential clients, etc. I believe this has helped quite a bit in terms of readability and structuring. And then we have the 09 version, which is currently the editors' copy, where we've done another large restructuring to help readability even more, and then a new introduction part to make that part a bit cleaner and clearer. And then the one big change that has been discussed a long time as well, and that is this combined DPoP mode, and a bit more graphical representation. So current state is basically we believe we have added most missing sections. We focused quite a bit on improving readability by restructuring, by rewriting introduction, the clarity of some of the statements, etc. And then there was this one big update that has been discussed since probably a year for this combined DPoP presentation mode that we now also have in the editors' version. And for that one, we would really, really, really like to see some reviews before we proceed. So we believe we have listened to all of the feedback in the past several IETF discussions on this, and then also with a few implementers directly. I believe it has improved also readability of the overall draft by quite a bit, and it's actually pretty nice combination mode now. For those not familiar, the idea was basically that if you would be doing a client attestation as client authentication and then combined with DPoP, you would have two PoPs basically. And actually a lot of deployments are planning to reuse the same key between those two. So the question was to introduce an optional feature that allows you to use only one PoP, where basically we remove the client attestation PoP, we only use the DPoP proof of possession, and that kind of does it for both then. We have added that after all of the discussions in the current way with both being header-based and with a clear signal for it to be supported by the AS by adding a new authentication method in the token endpoint auth methods supported. We believe this fits with everything that was discussed before, but we would be really, really happy to get some reviews on this, because this has been discussed for, I think, the past four IETFs. And now we finally merged the PR after a lot of discussion. So if this is something you're interested in, please review the current version, so the editors' copy. Any questions on the DPoP part and everything that was basically from the past two IETFs that we merged in? Denis.
Denis PINKAS: Yes, this is the first time I take a close look at this document, and basically I am very embarrassed with its content. The wording "attester" is not very well understood, I understand. What is a front-end and a back-end is unclear in this document because these terms are not well defined. Well, basically I understand that an attestation is some kind of certificate, like an X.509 certificate, but it doesn't have its format of course, but it's going to testify what are the characteristics of the application that is in the, I would say, in the wallet, and I think it's very important. So there is a trusted third party that is going to sign that attestation, and the first time the application will be requesting a credential, he will need to demonstrate that when providing the public key, the public key is indeed in a device that protects correctly the pair of keys. And I think it is fundamental. In order to do that, he needs to provide that information to the authorization server or to the issuer, and then he needs to disclose the identity of that device or that application. So there is a unique identifier. But I'm very embarrassed because at the moment the title is saying basically it's an interaction with an authorization server and a resource server. I believe the interactions are fairly different. First, there is interaction with the authorization server. In that case, it is needed to disclose the identity of the application, but not when it is with a resource server. The resource server is interested by the characteristic of the application, but for unlinkability reason, he shall not be aware of the identity of that application. So it means it cannot be the same protocol, cannot be the same information. And there is a way to handle that very easily, which is, since the authorization server will know the characteristic and the identity of the application, it can put the characteristic of the application into the digital credential without disclosing its unique identity. So this characteristic is not supported in any way in the document. So my belief is that document should be modified in a great fashion. I have prepared comments, but I had been awaiting for this session before sending these comments to see what you think about that.
Christian Bormann: So first of all, you seem to have a different mental model than we do on what the client attestation does. Because so there are two different modes right now. The main mode is that it acts as a client authentication, right? And there is an optional mode where it can be used at, for example, resource server. The important part here at that point, if you're using it like that, it is about a statement about the client at that point in time. It's not about the point in time when you went to the authorization server and got the access token. It's about the current state basically. What is the state of the client instance at that point in time? And that is what the client attester basically states.
Denis PINKAS: Well, if you do the protocol for authorization server and resource server, you cannot use the same set of attestation, because you will need a set of attestation for the authorization server that contains the identity of the application, but not for those for the resource server. So it will duplicate the number of attestation, which is not very good. And I mentioned a way where you can avoid that.
Paul Bastian: I think there are several options how you can do that, and basically the resource server could also trust the authorization server that he validated a client attestation and only under these circumstances issues an access token, for example. I think that was the original use case that we had in mind and there was feedback from the OAuth working group that there are several people that see use cases where it makes sense to also have an option to send this to the resource server. So being able to send this to the resource server is a direct feedback from this working group.
Denis PINKAS: Well, clearly I prefer the model where you can speak about transitive trust model, because if the resource server is trusting the authorization server, it can trust that it has made the verification correctly, so it can indicate the characteristic of the application into the digital credential and it's done.
Paul Bastian: But I think the model that I described is transitive trust, the authorization server verifies client attestation JWT and only then issues an access token that would be consumed by a resource server. So the resource server has transitive trust that the authorization server did the validation.
Denis PINKAS: Anyway, the resource server needs to trust the authorization server, otherwise he will not accept anything from him.
Paul Bastian: Exactly. So he can also trust the authorization server to check the client attestation or he... Exactly, exactly. So this is covered. So so what is your intent or your question? If you want, if you want to put very specific things like what is the version or a unique identifier of this device, then in our opinion this is already pointing to a very specific use case which we don't want to put into this draft because this draft is a more generic concept and we explicitly say that the client attester may put additional data into the client attestation JWT for specific use cases, but in this draft we don't do this because in our opinion this is the subject of an ecosystem, of a profile, of a very specific use case.
Denis PINKAS: This is too vague for me because for me there should be no protocol with the resource server in any way, otherwise as I mentioned you are making, you are doubling the number of attestation, which is very bad. So I believe that it should be written in clear text in the document and basically well, the structure should be changed a little bit, but also the important point is that it doesn't identify what is really fundamental in this architecture. The fact that in order to be secure you shall have a trusted execution environment, and which means that you shall have a trusted application in the TEE, which is called by a UA, untrusted application in the rich execution environment. And the attestation believe belongs to the TA, it doesn't belongs to the UA. So clearly it's going to testify the fact that the TA is a good application and a TTP is going to provide that attestation for that characteristics.
Paul Bastian: This is a totally valid use case, but this is already profiling our draft and you are thinking in the ecosystem of a digital identity wallet, but this is an OAuth draft. So this is like a general concept that could be used in many things that are not wallets, and there are people on this call that intend to use this in use cases that are not wallets. So doing these specific things and mentioning TEEs and other things does not make sense for this kind of draft.
Denis PINKAS: Well, the question is if you have an attestation, to which piece of software does it belongs to and to which piece of hardware it belongs to where that software is running?
Christian Bormann: But that is a question for that use case and for that specific problem you're trying to solve. Whereas this draft is basically one abstraction layer higher, where it says this is a general mechanism to make statements about a client instance attested to by some backend called the client attester, and you can use that in different kinds of environments, and one of the environments is something like that you're describing, but there are also other ones.
Denis PINKAS: In that case, we should have an annex describing what is more specific to wallets.
Rifaat Shekh-Yusef: Sorry, Denis, can we take this to the list, please? I think let the presenters continue with this, like if you have something that you want to kind of dig deeper into that topic and and maybe extend that the document that they're talking about, like let's take it to the list. Okay? Thanks Denis. Go ahead Christian, continue.
Christian Bormann: Yeah, so the first part would really be that we are asking for reviews for this DPoP combined mode, since this has been discussed to death in the past, I don't know, three, four IETFs, so please, if you're interested in that, review it. And then we have prepared a bunch of issues that we would like to have input on. And I guess Paul, do you want to take over the slide control or should I just press next always?
Paul Bastian: Yeah, just press next, it's only two more slides. Rifaat, did you want to say something?
Rifaat Shekh-Yusef: Yeah, yeah, so maybe can we get volunteers to review this document and the research changes, maybe two or three reviewers? Dave, David, thank you David.
Christian Bormann: And I think Philip has raised his hand.
Rifaat Shekh-Yusef: Philip. To sign up to review, yes. Awesome. Thanks Philip. Okay. Good. We have at least two here, so hopefully we'll get more. Awesome. Thank you. Thank you guys. Go ahead, Paul.
Paul Bastian: Okay, so what's the path forward? We, yeah, hope to close all the remaining issues that are in the GitHub tracker and the to-dos that may emerge from this call or from the mailing list. We currently have 17 open issues on GitHub, where like a bunch of those are like very clear, easy to-dos. We have a bunch that are marked as pending close, but there are also some open questions that we want to discuss on the next slide, but important to notice here that we think we're getting very close to the finishing line from our view, so we intend to start the working group last call hopefully in the next weeks. And to do that, we would like to discuss these four issues here that we have some open questions to. The first two ones are about whether we should bind other OAuth artifacts to the client instance. In our draft, we introduced the terminology of a client instance because the client could be referred to as, yeah, a group of deployments where a client instance is one specific instantiation running device that has a client instance key and then the client attestation is bound to this key. And then the question is, are other artifacts from OAuth bound to this client instance instead of the client as a whole? In the implementation consideration, we already say that the refresh token is bound to the client instance and the client instance key, and there are two issues that basically ask the fair question: are there other OAuth artifacts that should be bound to this client instance? For example, the authorization code, and I think we have something from CIBA. So, yeah, this is kind of like an open question where we can try to find all the things that make sense to explicitly mention which OAuth artifacts should be bound to this client instance. Does this in general make sense to have like a definitive list of things or should we describe this more general? This is one of the questions that we have. Filip, I think you are also the author of one of those issues, right?
Filip Skokan: That is right, at least one of them is me. The one thing that I would like to preempt and why I raised this is so that we don't need another draft down the road explaining how attestation based client auth or just the mechanism itself interacts with already existing extensions that we have. Especially ones that concern public clients such as device flow. We have an individual draft that describes DPoP and device flow because we just didn't think about describing that while we were working on DPoP. So to prevent doing this down the road for existing combinations of similar patterns where you have something lodged on the AS, such as a PAR request or the, well not the authorization code, the device code or a CIBA request ID, I think it would make sense.
Paul Bastian: Okay, so you are pro making a list of artifacts that would be bound to, to make it very explicit. And maybe one thing that came to my mind is you said the device code is using public clients. I just wanted to point out that feedback was from last IETF that we should explicitly say that this is not a public client, but a confidential client. So we would need to dig in if this is applicable.
Filip Skokan: That is absolutely right. The point is today these are 100% most likely public clients. If we make them use device, the attestation-based client auth on a per instance basis, then not only are they now confidential clients, but they can actually get that binding in addition because those codes are intended for the device. They're not for a group of clients.
Paul Bastian: Yeah. No, I think it makes sense. I think I just wanted to point out because there's so many OAuth extensions, this is a place where we would likely could need some help to make sure we have an exhaustive list here. I saw Brian raising his hand. Did you want to speak up?
Brian Campbell: I was going to say something to Filip that I can't quite remember. I think I generally agree with it, but let's just be a little careful not to bind everything we can willy-nilly because we can, rather put some, be intentional about what we do and don't bind. Like the authorization code, I think there's already quite a few mechanisms to cover this from DPoP to Pixy, so trying to put it in there might cause more problems than it helps. Some of the other ones, like I'm not really sure about, but just want to be maybe intentional about it.
Christian Bormann: How should we best proceed here? Do we have like a short call with the interested people to make sure we identify the right things to bind to or how to best proceed for that specific topic?
Rifaat Shekh-Yusef: Maybe take it to the list. You want everyone on the list to maybe chime in.
Christian Bormann: Okay. Sounds great.
Paul Bastian: Also, the second open question is one that's pretty old. Should we clearly explain relation to dynamic client registration? Should it be explicitly mentioned or not? I think this is worth bringing it up again because after the last update, we also said explicitly this may be used as client authentication, but it doesn't need to. So we can just use the header to make additional statements about a client instance. This is something that then could be useful for DCR. Is this obvious enough or do people feel we should explicitly mention the relationship to DCR? Is anyone currently in this call interested in that? Because I believe this was brought up a long time ago by a few people actually, but we haven't really heard or like seen the interest in bringing this up for DCR in the past like few months. Do we have those people on the call today that raised that issue, do you know?
Paul Bastian: I don't remember who raised it, I believe... Okay, so maybe it is something again to, to send to the list.
Christian Bormann: Put it on the mailing list, yes. Yeah. Well, I would say then in doubt, if no one speaks up about this, then I think we would close this issue if there is no desire for it.
Filip Skokan: What if you replace the three letters DCR with CIMD? Do we have any takers then? Because it's exactly the same topic, just not DCR, but CIMD [draft-ietf-oauth-client-id-metadata-document].
Rifaat Shekh-Yusef: Sorry, Filip, replace DCR with what?
Filip Skokan: Client ID metadata document, CIMD. Oh, I see. I see. Thanks.
Rifaat Shekh-Yusef: Brian?
Brian Campbell: Aaron was ahead of me.
Rifaat Shekh-Yusef: Oh, Aaron, sorry.
Aaron Parecki: I was planning on connecting the dots between this and CIMD at some point. So I don't know if that means in this draft or in a separate draft or in CIMD. I'm open to suggestions on that.
Rifaat Shekh-Yusef: So, just to make sure I understood, Aaron, so you still, you think there is a need to discuss DCR and you want to connect it to...
Aaron Parecki: Not DCR.
Rifaat Shekh-Yusef: Okay. So nobody's into, so you're not interested in DCR at all, right?
Aaron Parecki: No. But to Filip's point, CIMD, yes, that's the, that's what I would be, yeah. Got it. Okay. Thanks Aaron.
Brian Campbell: I was going to disagree with Filip this time. I do think CIMD is useful to understand and discuss here or elsewhere, or at least work through the use cases, but it is not just as simple as replacing DCR with CIMD. I think they're pretty different in how this might be applied to it, at least as the way I understood this 61 issue was really pushing things all around the different track, and this work, I think, could fit CIMD better than, than DCR. I didn't say that very well, but I agree with Filip but not in the framing.
Paul Bastian: Okay. Thanks for this. So how do we proceed? Aaron, does it make sense to have a closer look at this together in the next weeks? Do you want to have a look at this first?
Aaron Parecki: I'd be happy to do that. Yep.
Paul Bastian: Okay, then let's chat later and I propose we move to the third point, which has a very generic title. Issue 107 was about the way that the client attester gets information about the client instance. We deliberately left this out of scope how this could be used in the use case of like wallets or smartphones. There are, for example, certain things like this native mobile OS attestations, like Play Integrity, Key Attestation, iOS DeviceCheck App Attest, which could be examples, but we deliberately left them out because other use cases would have other signals that the client attester uses. And here the question is, is it better to just say, to just stay out of this game and say how the client attester is convinced that this is a valid client instance is out of scope and we don't make any further statements about this, or should we give more guidance that probably then includes some examples all non-normative? I believe if we do so, we probably need at least one more other ecosystem or environment where this could be useful and where we get examples other than just the smartphone world. Yeah, so open for feedback. Does it make sense to be more specific here? Give more examples or rather not? Brian, I'm not sure if it's an old hand or... it was an old hand. Then Denis.
Denis PINKAS: Yes, I would appreciate to have an example about digital wallets just to make sure that the document can fly with digital wallets. I'm not convinced at the moment that it can. So at least there should be an annex about that.
Paul Bastian: If you're not convinced then in general I can point you to a number of different documentations of wallet providers in Europe. You could look at the German architecture documentation, how we envision to use attestation-based client authentication to attest the device where the IDI wallet is running on. But I'm not sure if it's just about the understanding if it makes sense to include this in the draft or not.
Denis PINKAS: Well, I have serious concerns. I don't believe the vocabulary in this document is appropriate, starting with the wording "attestation" and "attester". So I think it's a big problem. So I will, I will send comments. Do you prefer comments on the mailing list or on the, by posting issues?
Christian Bormann: Could you explain what your concern is with terminology because we went through a past to align terminology with RATS and then have our own terminology section right now to explain where it differs, where it's the same, etc?
Denis PINKAS: I looked at the terminology of RATS very carefully and I believe it's wrong. That's one of my major problem. And I have prepared comments to explain why it's wrong.
Rifaat Shekh-Yusef: So, so then can you, can you go to RATS and comment on that there? So I don't think we can change those definitions in RATS here, right?
Denis PINKAS: Clearly, when we speak about attestation, attestation is a keyword reserved in the area of digital identity wallet or digital credential wallet to say it is an attestation about the characteristic of the application. Some people call it the mdoc app, but it is the that concept. So that is provided not by something you call a back-end or front-end or whatever. It is a trusted third party that is going to provide that attestation, and how it is, it arrives in the mobile device. Well, depends, but it can be installed when you get the mobile device. It can be updated with the OTA procedure. But so and so it means the device can come with its attestation or even in some cases a set of attestations if you want to have some kind of unlinkability between issuers. So there are various options. And at the moment, I don't recognize the correct vocabulary in this document.
Paul Bastian: I think this is, yeah, terminology is terminology. In Europe we call it attestations, other people would call it verifiable credentials, and then other people would say credentials are something entirely different than verifiable credentials. So terminology discussions are always very hard. I'm not sure if we'll solve it here. Some people think "attestations" is a good terminology and some people don't. I think if we're just like clear and we have a good terminology section that explains this and we're not, yeah, contradicting anything big, then I think we're fine and we have a clear translation how this relates to the RATS ecosystem. And the RATS ecosystem is something similar in the IETF world. So I think in the IETF realm we have quite a good state of our terminology right now.
Denis PINKAS: Well, I'm working in some ISO committee and the most important section in an ISO document is clause 3. So starting with good definition is fundamental and I took a look at the definitions that are present, they are not sufficient or they are not correct. So that's my major concerns. And starting from that there are many other implications. So once again the RATS document is incorrect, gives the example of a section of RATS, it has nothing to do with what is described in this document. But I will send my comments either on the list or on the by raising some issues.
Paul Bastian: Yeah, I just disagree with what you said terminology is wrong. I think terminology, terminology can't be universally binary right or wrong. Terminology is chosen by humans. For the original question, the one on providing more guidance on use cases. So we, we currently chose to not have very opinionated or like very strong descriptions on possible scenarios. We believe that is a better way to basically keep that away from this draft. Do people believe we should add very concrete examples? Like what might be part of such a statement, etc, or do you believe it should stay out of the draft? And maybe to, to also shine some light on on why we did not do it is because these mechanisms also evolve over time. When we started on this, there was a feature called Android SafetyNet. SafetyNet was replaced by Google Play Integrity in the meantime, so we also had the feeling that this may not age very well if we, if we put concrete mechanisms in there. Peter.
Pieter Kasselman: I would be in favor of not having that additional information in the spec. I think if somebody really has a very specific use case, creating a profile or some guidance document or something like that would work best. But I think you may end up over-constraining things or create the impression that this spec can only be used for those specific instances. And then I think, you know, certainly in the spaces where I'm working, a lot of things are changing sort of by the day and it's going to be very difficult to stay up to date. And so I think focusing on the higher level abstraction, the protocol level exchanges, etc, and then leaving some of the sort of specifics of implementation out of it and if somebody has enough energy or enthusiasm for it to go create a profile to describe the specifics, I think makes the most sense. We get the most, I think we get the most mileage out of that. Thanks.
Rifaat Shekh-Yusef: Okay. Emelia.
Emelia Smith: In the document itself, would it be worth not describing a specific profile, a specific mechanism that exists actually in real life, but actually just a abstract, okay, so this is what this attester needs, this is how the request gets sent and therefore we get this thing back that we can then use with this spec. I don't know if I'm explaining that correctly, but like an abstract idea of what is actually happening here as an example rather than as sort of more prose in the normative section of the document, having this as a non-normative, this is an example of what someone could build here if they wanted to and sort of provides the foundations for understanding them at a high level?
Paul Bastian: So you're proposing basically describing, for example, what's happening in the wallet ecosystem without explicitly mentioning any names and just being like a bit more vague.
Emelia Smith: Yeah, I think so. So like I think there might be a way that we can do it where we describe, okay, so we have some process that does device bound, like that attests that the device is a real device and then the client attester goes off and does something to verify that. Some mechanism, doesn't say what, but just sort of gives you like a step-by-step example of how someone could implement an attester if they wanted to and sort of provides the foundations for understanding them at a high level.
Christian Bormann: We kind of try to do that, in my opinion, in the introduction. There's a diagram now and after the diagram it basically has an abstract explanation of these steps, but without being very concrete, for example, what is the attester looking at etc.
Emelia Smith: Okay. It was just an idea.
Paul Bastian: Yeah, we can have a look if it makes sense to, to give some non-normative examples without actually mentioning technology. Okay, maybe to also highlight from the comments Tim said they regretted including platform specific mechanisms in WebAuthn, which is I think also like a good feedback. Thanks for this Tim. So after the discussion in the chat, I, I would lean towards not adding more use case or example descriptions right now, right?
Paul Bastian: Yeah, looks like it. Okay, if we were to mail to the mailing list anyway, we could write a short summary on this topic as well just to give other people who are not on the call the opportunity. Sure. Yeah. Yeah. That'd be great. And this brings us to the last issue, does client metadata make sense here? So this is from an issue where it was asked to provide metadata information about the supported algorithms for the client attestation. So both for like the signature that the client attester is providing and then also for the signature that the client instance is providing for the proof of possession. Our thinking here currently is that it makes sense to have metadata at the authorization server and we were intending to reuse existing token endpoint auth method alg supported for this one. And the question here is if it makes any sense for the client to also have metadata which algorithm he supports primarily for his client attestation key. We couldn't think of a use case how we use this because I think in general in OAuth, my mental model is that the client is doing requests and the client is fetching the AS metadata and then is basically seeing what's supported by the authorization server, comparing this to his internal knowledge of what he can do, and then he's basically making the negotiation. But I don't see much of the use case to have the client publish information about what he supports because he is usually taking the decisions and therefore doing the negotiation. And a question would be, does anyone see a use case why it could be beneficial to have the client publish metadata which algorithms he supports here? Aaron.
Aaron Parecki: Yeah, so this is a pretty big change that's happening with the adoption of client ID metadata documents, which is clients sharing what they can do with an authorization server that hasn't seen it before. So this is definitely a change of the model in of how OAuth's typically been deployed, but it's quickly ramping up adoption right now. So I wouldn't, I need to think through the specifics, but it seems like it would be very reasonable to need the ability to do that.
Paul Bastian: Okay. Could I ask you to volunteer having a look at issue 170 and make up your mind and post a comment there if you believe it makes sense or are you like already convinced that it definitely makes sense and you don't need to look into this?
Aaron Parecki: I will review that to see if there's more context.
Paul Bastian: Cool. Thanks. Any other people have opinions on this issue?
Filip Skokan: There's, you mentioned reusing the algorithms, the AS metadata algorithm registry, and I think this translates to the client one as well where, specifically with client ID metadata documents, if the client... well I may be getting mixed up here. The AS may actually support multiple authorization, multiple token endpoint auth methods that do require an alg, in which case there could be client secret JWT and all of a sudden you have HS256 in the list, there could be private key JWT so you got PS and RS. Maybe for attestation client auth then you have a different set of algorithms, we can't discern that. I don't know if that's a problem or not, I can't think of it being a problem, just it makes the water a little bit muddy. It's not so cut and dry. With the client side metadata you only have one auth method. So it's not a problem there, I think. I don't know, you asked for an opinion.
Paul Bastian: Yeah, part, yeah, our other OAuth methods reusing the existing token endpoint auth methods supported algs? So is there precedent for OAuth mechanisms reusing this?
Filip Skokan: Yes, so both client secret JWT and private key JWT use the same one, but there's a clear distinction because one only has the symmetric ones, the other one has the asymmetric ones, so you can make a clear distinction. But now we would be adding another asymmetric one.
Christian Bormann: And to be clear, right now in the draft, we have a separate value for that. I think it's called client attestation signing alg value supported and client attestation PoP signing alg value supported and basically one of the side discussions in that issue was: should we just reuse the existing ones instead of introducing new ones? And I guess from what you said before, it would be better to reintroduce the new one to have a clear separation.
Filip Skokan: I can offer my time to have a look at it in more detail.
Paul Bastian: Yeah. So my perspective on this was on the AS it's this is just verification. There isn't any hardware constraints underneath that would limit this. So this is basically just does the AS software have a code path for certain algorithms or not, which is also regarding Brian's question in the chat that I think it doesn't make any sense to differentiate between the algorithm of the client attestation JWT and the client attestation PoP JWT because from the AS perspective, that's just code. If you have the code for the client attestation JWT, then you could obviously easily reuse this for the PoP JWT, so having one there makes sense in my opinion. And then the same also applies for reusing this for other client authentication methods like private key JWT. I could only think of a separating these making sense if I basically have different libraries underneath and those both libraries don't support all the algorithms. If I have one software that's doing the verification for both, then obviously I would reuse the same code path for these things and then a unified JSON support claim entry makes sense from my perspective. And I think in my opinion it's much more realistic that both would come from the same library. But I'm open here if people think it makes sense to, to split this in two, then we will do that. I think we don't have strong opinions on this one. Emelia.
Emelia Smith: We can't hear anything if you're talking.
Emelia Smith: No, no, I was waiting to speak. In the spec it currently mentions client attestation signing algorithm value supported and then client attestation PoP signing algorithm values supported. Is, based on this conversation, what I'm hearing is both should be probably the same values, so would it make sense to just collapse them down into client attestation algorithm values supported instead of making two different ones between signing and PoP?
Paul Bastian: Yes, exactly. That was the first argument and then if you follow this one, then why shouldn't we reuse the existing token endpoint auth methods algorithm supported that already exists? And it already includes the one for private key JWT. Yeah, exactly. I think I would reuse rather than defining new properties to be honest in the authorization server and probably also in the client if they're just going to be the same thing.
Paul Bastian: Yeah. Thanks. Anybody else? Otherwise, this is it for the feedback for the questions. Sorry, thanks for your feedback. We'll summarize these points, bring them to the mailing list, and continue working on this and hopefully, yeah, bring this to the end in the next weeks.
Rifaat Shekh-Yusef: Okay. Awesome. Thank you, Paul. Thank you, Christian. And thank you to the group and we'll see you next week.
Paul Bastian: Thanks Rifaat. Thanks everyone.
Christian Bormann: Thanks a lot. See you.
Rifaat Shekh-Yusef: Yeah.