Session Date/Time: 17 Mar 2026 03:30
00:00 - 00:24 [Music]
00:24 Loganaden Velvindron: All right, looks like about time and looking through the participant list, it looks like the usual suspects are assembled. So let's go ahead and get started.
00:51 Loganaden Velvindron: Assume you guys can still hear me in the room.
01:03 Speaker 2: Yeah, I can hear you fine.
01:04 Loganaden Velvindron: Good, thank you. All right, so this is the ACE Access and Authorization for Constrained Environments session at IETF 125.
01:17 Loganaden Velvindron: Here is the Note Well that it's still early in the meeting. I know some of you have probably seen this, but by participating you agree to all of this, including behaving professionally and paying attention to IPR and a bunch of other processes and procedures. If you have advice, please either talk to one of the chairs or the area director. You need to look at this if you have not already. I think everybody here is an IETF veteran, but if we have new people, please take a look at that.
01:57 Loganaden Velvindron: And in particular, please treat each other with respect. Please discuss the ideas, not the personalities.
02:08 Loganaden Velvindron: We have a relatively short-ish agenda today. So these are the drafts we've got that are active right now. There are two that are making their way through various stages of the IESG process. So hopefully at the next meeting we'll have some RFCs to announce as well, quite possibly two of them. Any other notes from the AD?
02:41 Paul Wouters: From the AD? No. I've done what I could and I'm handing it over to Chris, I think. Or Deb, actually. No, I think it's Chris.
02:54 Loganaden Velvindron: We will figure out who you're handing it over to and thank you Paul for your—all of your work being an AD is hard. So thank you very much.
03:06 Christopher Wood: It is Chris, so I will be the new AD.
03:10 Loganaden Velvindron: Oh good. Thank you. All right, I'll get in touch with you at some point and we can chat about what's going on and I'll help get you up to speed.
03:22 Christopher Wood: Sounds great.
03:23 Loganaden Velvindron: Good. All right, in that case we're up for our first presentation, Protecting EST Payloads with OSCORE. Let me see if I can find the slides for that one.
04:06 Loganaden Velvindron: Do we have slides for this one? I'm seeing the profile slides, but not the...
04:12 Mališa Vučinić: Oh, I uploaded them yesterday. I don't think they have been approved.
04:18 Loganaden Velvindron: Let me go—let me go find that, yeah. Thank you. That's probably what's going on.
05:23 Loganaden Velvindron: It's a little bit late here, so I'm a little slow.
06:40 Loganaden Velvindron: All right, they should be approved. Let me see if I can find them. There we go.
06:43 Mališa Vučinić: Okay, great. Thank you so much. So this is Mališa speaking from Shenzhen. And this is the presentation on draft-ietf-ace-coap-est-oscore, protecting EST payloads with OSCORE. Could you pass me the slide control on the slide clicker?
07:07 Loganaden Velvindron: Sorry about that. Done.
07:09 Mališa Vučinić: Okay, great. Yeah, so this draft has been in Working Group Last Call since 18th of September 2025. We had two reviews on the list. Marco and Esko kindly provided the reviews in October. So there was a first set of comments that were addressed for IETF 124 in November. So these were discussed at the ACE IETF 124 meeting in November. Following that, we had a couple of unresolved issues on the draft that were resolved in dash-10. And this version was submitted on 2nd of March 2026, which addresses the remaining open issue. And my presentation will be quite short. I will just discuss the main non-editorial issue that was resolved, and then ask for the document to be shipped.
08:14 Mališa Vučinić: So this is the list of resolved issues since 09. So there as you can see there is five issues on—these are all listed on GitHub, they are tracked on GitHub. Most of them are editorial. First one is a syntax error in the example that was brought up by Esko in his review. Second one I will discuss in the meeting today. Section 3 normative language, or issue number 114, was discussed at IETF 124 and was correspondingly fixed. It's kind of an editorial issue. And then we had some discussions on two of these with Esko following the publication of 09.
09:07 Mališa Vučinić: So the main issue that was resolved since the last meeting is 113: whether a bag of certificates is mandatory or not. You can see the pointer to the discussion with Esko on GitHub. And the conclusion of that discussion is that supporting explicitly a chain of certificates does not make sense in this context. So Esko provided some compelling arguments which we adopted and we—which—which are listed on this slide. Namely, the explicit chain of certificates in return to CA certs does not allow us to re-key CA certs after the deployment. And in any case, for specific use cases, a bag is more general than a chain, so it can contain—it can contain a chain. So the structure that is defined in IETF draft in COSE, COSE C509 cert support either a single certificate or multiple certificates and thus a bag can be returned in this data structure. So what we did is that we made the—this type application COSE C509 cert must support for both EST-OSCORE clients and EST-OSCORE servers. We aligned the TBD numbers, the magic numbers that are to be allocated by IANA, with draft IETF-COSE-CBOR-encoded-cert. And we did the editorial fixes in the example throughout the manuscript—throughout the—throughout the document.
11:00 Mališa Vučinić: There was another issue on—on handling certificates by references. We clarified that mixing X5U and C5U certificates, or—this is for context this is X.509 references and CBOR-encoded references in the same multipart response is not supported because they are of the same application CBOR type, so it would be ambiguous to carry them in the same multipart response. So we avoided mentioning X5T and X5U references in the document as a consequence of this. And the certificate references that are supported by this document are CBOR-encoded certificates. So these you can find more about these in the GitHub and in the issue tracker with linked corresponding pull requests. The diff is quite simple as you will see. And with that we resolved all the remaining issues on the draft and we believe the draft is ready to be shipped outside of the working group.
12:14 Loganaden Velvindron: All right, thank you. Any comments on the readiness of the document for Working Group Last Call from anyone in the audience or online?
12:28 Speaker 5: All right, seeing no feedback, we'll take that to the list.
12:32 Mališa Vučinić: Okay, perfect, thank you.
12:34 Loganaden Velvindron: Thank you. All right, up next is the CoAP Publish-Subscribe Profile for ACE, Marco.
12:42 Marco Tiloca: Hi everyone. All right, you have to pass control of the slides first, or take the next deck and hand it to me, whatever.
12:51 Loganaden Velvindron: All right, try again, it should work now. Oh you... yeah. We both hit it at the exact same time. Go again.
13:07 Marco Tiloca: Okay. Try again. It's like I don't have control yet. Oh, there we go.
13:21 Loganaden Velvindron: There's a couple of race conditions.
13:24 Marco Tiloca: Yes. Okay. This is an update of the PubSub profile of ACE. Yeah, as a recap, this is an application profile of RFC 9294. So it's about building on ACE to distribute key material for group communication and in this particular profile, group communication is based on PubSub and in particular the PubSub architecture for CoAP specified in a CORE working group document. It's interesting here to see that the ACE client is basically any publisher and/or subscriber node, but we have two resource servers involved. One is the broker for dispatching published data, and one is the Key Distribution Center defined in RFC 9594 to distribute the key material to protect end-to-end the published data using COSE. There's only one authorization server though, that is supposed to issue, consistent with what I've said before, two access tokens for the client. One is to be uploaded to the broker for the sake of authorizing publication or subscription operations, and one is issued again to the same client for the sake of accessing the KDC and obtaining the key material to protect end-to-end the published data using COSE.
14:51 Marco Tiloca: So what happened recently? The document was in Working Group Last Call until January. We got positive feedback, mostly editorial. Thank you. And also comments from the author team. And those comments were largely about taking advantage of the comments received during the IETF Last Call of the other application profile, Key Group Comm OSCORE, that as expected were largely applicable also to this document. So the latest version 03 is in fact about addressing those comments as they fit into this document and also one additional point that was also mentioned during the Working Group Last Call about an under-specified optimization that now should have been better specified.
15:46 Marco Tiloca: Yeah, starting from the comments made to the other document and considered here too, of course consistent with the present document, we have extended the introduction first of all in text to clarify how this document relates to the relatively many other documents it builds on. And this is also supported by an ASVG diagram showing the relations with references also as a footer.
16:17 Marco Tiloca: Yeah, then again building on those comments, we rephrased the paragraph to make it hopefully very clear and explicit what we means by saying that secure communication has to be used among the involved participants in the protocol. And yeah, with the exception of the published data protected end-to-end with COSE, the actors are supposed to rely on the security protocols as defined by the transport profile of ACE used. For example, the OSCORE profile of RFC 9203 between the client and the broker. So with that text displaying the slide, it should be hopefully clear now. On multiple sections, taking into account I think a comment from the SECDIR review of the other ACE draft, we have made it very explicit what possession is proven about when talking about proof-of-possession, and it's clearly the private key of the prover. That touches multiple sections here, just an example from one of those.
17:24 Marco Tiloca: And finally, when considering those comments, we also restructured a bit the paragraph listing now one by one in the right order the possible reasons and occasions when the KDC can perform a group rekeying, where the group here is the assemblance of the publishers and subscribers. So it can be because a member leaves, or because a new member joins, or for other reasons like periodically scheduled rekeying. That was all when it came to those comments.
17:58 Marco Tiloca: But then as I mentioned before, we also raised during the Working Group Last Call an under-specified optimization. That's the case where a group member rejoins the group or joins another group, but he doesn't have necessarily to provide the KDC with its own authentication credential again because maybe that happened in the past during a previous join or through other channels. So it's fine in that case to not necessarily provide the credential again, but it's not just as simple as omitting the parameter altogether in the request. That would be a violation with respect to RFC 9594. So the trick was to keep the parameter to remain compliant, but instead having it encoding a sentinel value like the empty CBOR byte string to suggest that the KDC should just reuse the already known authentication credential. And that was about the exact semantics used in the request payload and then also revising some text in later section conceptually replacing the absence of the parameter that was wrong with its presence encoding the sentinel value.
19:10 Marco Tiloca: Then we also added, building on the comments on the other document again, a new section: Operational Considerations, that is increasingly expected and in the near future I have the feeling it will be formally expected. Have a look at the OPSAWG draft for more information. We have added this section about this topic and it's very much in the same style of the corresponding section we had in the other ACE document. It mostly discusses the relevance for logging some information at the KDC, essentially events related to the interaction of clients with the KDC, in case of error or not, or events driven by the KDC, for example, group rekeying. Also pointing out that secret information must absolutely not be logged and in the case the logs are shared with third parties, those are really supposed to be further redacted to remove possible privacy sensitive information in them. On the other hand, it's out of scope any operational consideration related to what goes beyond the actual PubSub communication here, meaning any possible administration of the security groups or of the application groups, meaning the topics where nodes can publish.
20:39 Marco Tiloca: So what's next? We are on version 3 now. I believe a version 4 is worth it. I'll mention why in the next lines. And in fact, I have the tentative content already available in the GitHub editor's copy. It's mainly about adopting now comments applicable here too that were made on the other ACE document after its IETF Last Call, so during IESG evaluation. And an outstanding one was from the review of Deb that was a discuss ballot about the inappropriate use of the words nonce and challenge that had to be correct and more consistent. And then there were more minor clarifications coming from other reviews during the IESG evaluation.
21:35 Marco Tiloca: Other than that, I noticed when reasoning about this that we have always worked on this document making very reasonable assumption that it'd be worth stating very clearly up front. Meaning the topic data resource where a publisher sends a request to publish the data is assumed to be hosted precisely at the broker. While in principle, this CoAP PubSub architecture admits that resource to be hosted somewhere else yet at another server. So the addition here would be to clarify that we are intending the topic data resource to be at the broker in this profile and an alternative to that is out of scope. If you think about that, it would mean yet another token, so a third access token for granting permission to publish and subscribe at that other server. But I think it's safe to keep it out of scope from this particular profile. So if there's no particular objection to that or outstanding comment, I would proceed taking the editor's copy and making a version 4 that I can submit anytime soon.
22:52 Marco Tiloca: And then we should probably really be done. I just point out this document has of course a normative reference to the CORE working group document defining the CoAP PubSub architecture. It's in version 19 now. It's going to be presented at the CORE session later this week on Friday. So I suppose it's best to have the CORE working group document sent to the IESG first and then follow up with this ACE document, although the Shepherd Write-up can start already or earlier than that, probably. That's all I had. Thank you.
23:31 Loganaden Velvindron: Okay, I think if we're going to wait, we should probably—I wouldn't start on the Shepherd Write-up or anything like that because when the other document gets through, we might have things to do. Hopefully not, but I think maybe we just put it in a holding pattern for now and see what happens and we'll get back to it when it's no longer blocked. We could push it forward and just have the dependency, but I think that's probably more work than it's worth.
24:00 Marco Tiloca: Okay. Then I'll send out soon version 4 and by the way, there's no shepherd appointed yet. But since it's not urgent, we can think about it.
24:11 Loganaden Velvindron: Yep, we usually do those when we need them. But thank you. All right, I think you're up next with Short Distribution Chain (SDC) Workflow and New OAuth Parameters for ACE. Is that right?
24:19 Marco Tiloca: Yes, I should be able to change the deck myself. All right. Yes, this is an update on another working group document: workflow and params. Yeah, to recap, this is updating the main ACE framework specification RFC 9200 on a number of points and to a minor extent some other related RFCs. It mainly defines the new alternative workflow that we name SDC where the authorization server uploads the access token to the resource server on behalf of the client. And it's extending a number of endpoints, mainly the token endpoint and the AS, but also the authz-info endpoint and the RS, with a number of additional parameters in support of the new workflow, but also to improve the provisioning of authentication credentials to the client. It's also in that respect allowing client and AS to coordinate on the exchange of authentication credential by value or reference, a few new error codes, we're deprecating the original format of the payload for error responses switching to problem details from RFC 9290 and we are slightly amending two requirements for the transport profiles of ACE.
25:42 Marco Tiloca: So what happened recently? Other than really minor editorial improvements, yeah, I noticed that there was a mixed wording about the inclusion of parameters in messages. I tried to make that more homogeneous, saying for example always optional to include in and must be included instead of required. And for a number of parameters, maybe it was obvious already, I preferred to make it explicit: they don't make sense when they come together with the issue of an access token that is not the first one in a token series, but is extending an existing token series for the sake of dynamically updating the access rights of the client. The parameters are mentioned here. Now it's explicit where they must not be included because it doesn't make sense in those cases.
26:33 Marco Tiloca: Specifically for the parameter RS_CNF, we have been already extending its semantics for a while compared to the original definition of RFC 9201 to be also included in an access token request. The purpose is unchanged for a while, it's still about the client giving guidance to the AS about if and how including the authentication credential of the resource server in the access token response. So its use was pretty clear already. I tried to make it clear now how this parameter works for its non-use. And if the client doesn't have really the authentication credential of the RS, it really makes no sense to include the parameter with value null, which means give me nothing, because the client has nothing already. So that's why the 'must not'. The parameter included with 'false' would mean give me a reference that's good enough. Yeah, same, if the client doesn't have the credential of the resource server already, this doesn't make much sense unless the client is really sure that it can build on that reference and use it to retrieve the credential by other means, for example, a trusted repository. And that's why the 'should not'.
27:53 Marco Tiloca: Okay, then for better or worse, the ACE framework allows messages to be encoded in CBOR or JSON to some extent for compatibility with the OAuth ecosystem. So I took care of specifying in detail how it works in case those messages are encoded in JSON and essentially spelling out explicitly this parameter is encoded this way if the message is encoded in CBOR or the corresponding JSON encoding if the message is encoded in JSON instead.
28:30 Marco Tiloca: On to the IANA consideration, I noticed one thing was missing. This document is registering of course a number of new parameters, but it's also extending the set of messages where existing parameters can be used. So it's also about updating existing entries in some registries. One entry to update was not mentioned yet. That would be in the OAuth parameters registry, the entry about the access token parameter. We were missing the update related to the possible use of the parameter also in the AS to RS request consistent with the new workflow for updating the access rights, sorry, for uploading the access token.
29:19 Marco Tiloca: More clarification: I avoided the expression 'successful access token response' because checking carefully RFC 9200, the access token response is successful by definition, so it's just sufficient to say access token response. On the other hand, successful responses that can have different codes were instead all conflating into 201, which is not really accurate. So I prefer not to be explicit on the response code otherwise necessary and just talk of a successful response where appropriate.
29:55 Marco Tiloca: Then a kind of major editorial improvement, thanks a lot Dave for yet another feedback you gave in Montreal. That was about the subsection 'token upload' in the section 2 mainly describing the new workflow where the AS uploads the access token to the resource server. The comment from Dave was that section intentionally discusses the token upload in that new workflow, but it has too much text about the subcase where that is done for the sake of updating the access rights. It makes the section noisy. So it's just better to move somewhere else forward that particular content and point to that. Well, we did it. Now section 2.1 has five paragraphs less that were moved forward in the more specific section about that topic, section 3.7. Section 2.1 just mentions the possibility to use the new workflow also for updating the access rights and then the details are discussed in the later section 3.7.
31:02 Marco Tiloca: More feedback from Dave actually, but I need to recap a bit of context for that. When using the new workflow, there's a particular thing that can happen that we noticed already in version 6 and was mentioned in the previous IETF meeting. Imagine a client that already obtained an access token, uploaded it, secure association with RS established, all fine. Later on, the same client asks the authorization server to issue a new access token in the same token series. So for updating dynamically its access rights. That works. The AS issues the access token and goes on from there using the new workflow. So the AS tries to upload the access token on behalf of the client at the resource server. But something went wrong at the resource server that, for example, due to memory limitations, had to delete the old access token to supersede and terminates with that the token series and the secure communication association with the client. Because of this particular reason, the resource server replies with an error to the AS. The AS gives up with the new workflow and just replies to the client, "Sorry, I tried, I failed. Here's the token, you can continue."
32:28 Marco Tiloca: We were aware of that already and the question from Dave was, well, what next? Can you clarify? We already added a paragraph clarifying explicitly what happens next. Well, the client will follow up using the token obtained from the AS and the client will fail too because from the client point of view, the secure communication association is still ongoing although it's not on the resource server. So the resource server will reply with an error. The client now is really lost and can possibly ask for a brand new access token more starting a new series at the AS. So what happens next is clearer now. But can we do better than this?
33:11 Marco Tiloca: We think so. This is not in the draft yet, but we plan to include it in the next version. If that particular situation that I described occurs, we can do something better. Take a step back again on the AS failing to upload the access token at the RS and the RS replying back to the AS with an error. Well, in that case, in that particular case, the AS can instead locally start a new token series issuing yet another new access token, say T_new2. And its scope would be exactly the scope of the access token that was failed, for which the uploading failed at the resource server. But beyond the scope, anything else would be essentially the same as in the token series for which the failed token upload just happened. And all that other information is the same as in the old original access token request that started the token series of the latest access token for which the upload failed. So the AS in practice starts a new token series with its first access token T_new2.
34:31 Marco Tiloca: But what then? Well, it depends. If the client made that original old access token request also including the parameter 2RS with information to be conveyed to the resource server, well, then there's nothing the AS can do much more right now and it really returns the latest issued access token T_new to the client, and the client can take it from there and now it should work for the client. But if in that old original access token request, the client didn't add that 2RS parameter with information to be conveyed to the RS, then the AS can do even better and consistent with the requested use of the new workflow from the client, the AS can try to upload this T_new2 access token to the RS again using the new workflow. There's no risk of loops, there's no risk for the root of the problem situation to occur here because this is the new first access token of a new token series.
35:38 Marco Tiloca: These are the steps that I imagine to happen. But what do we need to have in the draft beyond the steps themselves? Well, the AS needs to know from the resource server that exactly that situation occurs and we can do that thanks to the error response that the resource server returns to the AS by defining simply a new ACE error code to be included in the payload of that response. Now, this is interesting because ACE error codes were originally defined to be used in responses imagined from the authorization server to the client on the resource server, and here it would be in an error response from the RS to the AS instead. But there's fundamentally nothing forbidding the use of ACE error codes in different messages than those imagined originally. The AS also needs to remember the original access token request that started the terminated token series, but this is already happening, otherwise we couldn't enforce the dynamically update of access rights in the first place. And finally, when providing an access token response to the client with the new access token in there or not depending on how the uploading is actually supposed to work, we have to tell the client what exactly has happened, meaning I know you asked for dynamically updating access rights, but actually that precise thing went wrong and I've just started a new token series. Here's the token or an indication that I successfully uploaded the access token to you. And to give that indication to the client, well, that can happen in that same access token response using the same new 'token_upload' parameter that we are defining here just with some new possible values that it can encode. So that's the planned improvement that I'm confident we can have already in the next version of the document.
37:48 Marco Tiloca: Yeah, that's all on the draft itself and sorry for being a broken record. I've been raising this slide for a few meetings now. Thanks a lot to the work done in this document, we have filed a number of errata against RFC 9200, the main ACE framework specification. Please review them so that at some point they can be rejected or held for document update or right approved, whatever. And that can play a role in some more text that we may want to add in the present document actually.
38:25 Marco Tiloca: Okay, as the next steps, we still have to properly extend the security considerations and as mentioned also in the previous presentation, it's good to add an operational consideration section according to expectation. I believe there'll be quite some things to say here, also considering that the original ACE framework specification didn't exactly provide a section about that. It wasn't expected at that time. So in doing that in this document, we can actually take the opportunity to make that section another formal point of update to RFC 9200. Yeah, I also noted after submission unfortunately that the semantics of the 'from_RS' parameter should be a bit improved. Right now it is really tied to the inclusion and value of the '2RS' parameter, but that's actually not necessary. It is really possible to decouple those and the '2RS' parameter presence and value really play no role on 'from_RS'. And then the point I discussed in the previous slides, the improvement on the AS starting on the fly a new token series if that particular situation occurs. And finally, we also have an old time now GitHub issue open by Christian Amsüss on the GitHub on giving more guidance when 'anchor_cnf', one of the new parameters, is used when issuing access tokens targeting group audiences. Till then, comments and reviews are very welcome. Thank you.
40:13 Dave Robin: All righty. Yes, thanks Marco for all your editorial cleanup. This is a lot easier to read. You spent a lot of time on just the wordings and so anyway, but I appreciate moving all the old and new stuff further down in the document was a good idea, makes it easier to read. Although now section 3.7 is really big, but that's okay, it's the details. If you read that far, you're willing to put up with the big paragraphs. Um, it was funny though you had on I think on your second slide a mention of this RS_CNF thing and how you changed it from "you must not send a null" but "you should not send a false." And that's funny because I wasn't expecting to see that on your slide. That's exactly what I was going to bring up in this meeting, that I was confused by when I read that section. And so just this, right now it reads "you must not send a null, you should not send a false." I still think that needs more—that's confused—but I can send a "high world"? I mean, you know, I'm not sure the interpretation between "must not" and "should not" leaves something to be...
41:43 Marco Tiloca: What needs to be highlighted in the draft is probably that sentence "if client does not have RS authentication credential." So those are the situations where those values don't make much sense in that case, with the possible exception for false.
42:03 Dave Robin: Well see that's the problem with it. It is saying "should not send a false," but you might want to in this case seems to violate the "should not." I mean, I was confused by "must not" and "should not" being next to each other without saying why I might want to violate the 'should' a little more, I think. Just seemed kind of confusing head-scratcher with the combination of the "must not null," "should not false." It just needs more words, I think.
42:29 Marco Tiloca: Okay, I'll try to elaborate more.
42:31 Dave Robin: Other than that I think everything else was really clarifying. I did not go through all the JSON stuff, it looks right but I'll make another pass at that. So thanks for your work on this.
42:53 Marco Tiloca: Thanks for the feedback.
42:56 Loganaden Velvindron: There was a comment from Christopher in the chat. Yeah, so if there's nothing meaningful to say, as I understand the OPSAWG draft, one is still supposed to add the section with a one-line boilerplate and an explanation of why there's no considerations.
43:20 Christopher Wood: Yeah, so that hasn't been fully agreed upon. And so I mean, as future AD I guess, you know, if that's an argument that needs to be made that I don't want you to put in an operational consideration section and say nothing to say. Right, so if that's the case, I'm willing to carry water there and say that that doesn't need to be done.
43:50 Marco Tiloca: Thanks. We haven't thought through the details yet. I suspect there will be something to say, especially from the point of view of the authorization server and especially about its logging.
43:59 Christopher Wood: Yeah, so if there's something meaningful to say and something that would make, you know, operating this, "Hey if this happens, this should be logged and this should be checked," if you have something to say in the operational section, by all means. But if you don't, don't put it in there.
44:15 Marco Tiloca: Sure. Thanks.
44:22 Loganaden Velvindron: All right, that looks good. I think we have just enough time for the final presentation. Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for ACE.
45:00 Rikard Höglund: Yeah, hello everyone. My name is Rikard Höglund and I will be presenting updates to the EDHOC and OSCORE profile of ACE, which is now reached version 10. And just as an overview, what is this about? Well, it's a profile of the ACE framework using EDHOC to do the actual key establishment where the access token is uploaded in an EAD item, and then it's using OSCORE for the actual secure communication based on the keying material derived through the EDHOC execution. And you can see the workflow here, an example workflow where you start by running EDHOC and you can also see that in this example we're using the optimization such that we're actually combining two of the OSCORE messages. One thing to note though is that this can also be run in the reverse message flow. This is an example of the forward message flow. But basically you request the access token, you post it, you execute EDHOC there in steps 1 and 2 on the right. In step number 3, the first OSCORE request combined with the EDHOC message number 3 and in EDHOC message number 3 the access token is included in an EDHOC EAD item.
46:24 Rikard Höglund: And to go through some of the updates we did for version number 10, first of all, we removed a number of parameters from the EDHOC information object. And this was based on feedback from some previous IETF meetings and discussions. And just to mention that the EDHOC information object is providing information to the resource server and client on how to execute EDHOC with each other. For instance, what ciphers to use and similar details. However, some of the parameters in this object were excessive or a bit unclear in how useful they actually are. So we decided to remove four of these parameters about the maximum size of messages, usage of the CoAP content format option, endpoint identifier types, and the actual transports used. And as a side effect of this, we could also remove two registries for the transports and the EDHOC endpoint identifier types. We also did a number of editorial fixes and improvements and also some minor updates based on an IANA early review.
47:42 Rikard Höglund: Another thing we did is fixed some CDDL notation describing this EDHOC information object and here you can see a better illustration of what it actually contains. So basically we noticed that the CDDL definition did not actually validate. So it's now been updated to be correct. And if you see there on the left-hand side, all the green boxes have been updated and those four items in the red box have been removed. And well, basically as you can see, there's been a number of updates. One main thing I would say is about the trust anchors where we simply had map before but now we actually define this in proper CDDL.
48:33 Rikard Höglund: Another thing we did is defined how the 'NS' is derived when you're combining this profile with specific application profiles of ACE. So what's the scenario? Well, you can use this EDHOC and OSCORE profile in combination with some ACE application profiles such as Key Group Comm OSCORE and the ACE CoAP PubSub profile. Now the problem is that those profiles require the client to receive a challenge 'NS' from the resource server and 'NS' is in turn used by the client to perform proof of possession. Now the problem is that in this profile that we're defining, the client does not actually upload the first access token of a token series to the .authz-info endpoint. As I said instead the access token is placed inside an EDHOC message inside an EDHOC EAD item. So it's actually uploaded during the execution of EDHOC itself and not .authz-info. And because of this, 'NS' is never received by the client. So because of this, we propose a solution that when this profile is used, you actually derive 'NS' by means of the EDHOC exporter. So basically you can see the actual details on how you do it. You have a specific EDHOC exporter label and we propose registration of two labels, 26 and 27, for the two application profiles, the Key Group Comm OSCORE and the CoAP PubSub profile. You specify the context parameter and you specify the length parameter and then you invoke the EDHOC exporter as you can see there in the image how it's defined. And as output of that invocation, you get 'NS'. And well you obviously invoke this on the EDHOC session that the client and resource server are sharing.
50:38 Rikard Höglund: So another point we wanted to raise is to propose early allocation of some code points. We would like to do early allocation for three registries actually and this is also something that was raised through feedback from other IETF collaborators. The first registry is the JWT confirmation methods and you can see there a number of items we would like to propose for early allocation. The second registry is the CWT confirmation methods and there you can see a number of items and our proposed integer values. And finally, we would like to do it for the EDHOC external authorization data registry and here we actually have one value 'credential-by-value' which is already today in use by AIO CoAP and Ariel OS CoAP core. So this is something we would like to raise also now, to propose to do this early allocation.
51:41 Rikard Höglund: Yeah, so what's our next steps? We have a number of open points. I tried to highlight some of the more important ones. One thing we want to elaborate a bit more on is the privacy and security implications of including the access token in EAD_2, EAD_3, or EAD_4 because like I mentioned, we support both the forward and reverse message flow of EDHOC and depending on the flow, you would place the access token in—well basically you can place the access token in different of the EDHOC messages. So EAD_2 is message 2, EAD_3 is message 3, and EAD_4 would be message 4. So now depending on the flow and depending on where you are placing the access token, that can actually have results in terms of privacy and security. And we would like to have a better kind of overview of those implications. Another point we would like to do is a bit more extended example of usage of this request creation hints EAD item. And that's basically a way for the client to ask for request creation hints and the RS to provide request creation hints through an EDHOC EAD item. We also would like to process Christian Amsüss's review of version 09. Another point is that since the AS is producing this EDHOC information object, it needs to have information that's accurate with regards to how the client and RS should execute EDHOC. So it's important that the AS is kept up to date about the capabilities of C and RS and how they would successfully execute EDHOC with each other. Yeah, and that's just to mention any comments and reviews are very welcome. So thank you all for listening.
53:32 Loganaden Velvindron: All right, thank you. Any comments or questions?
53:45 Loganaden Velvindron: All right, in that case, thank you everyone. It looks like we have one action item coming out of this, which is the Working Group Last Call for CoAP EST OSCORE.
54:02 Mališa Vučinić: So CoAP EST OSCORE is already in the Working Group Last Call, so this is concluding Working Group Last Call.
54:12 Loganaden Velvindron: Thank you for the correction. We are finishing—we are concluding the Working Group Last Call and we will write up the Shepherd Write-up. Thank you. In that case, you still have permission to have a nice rest of the day. So thank you everyone.
54:29 - 55:14 [Music]