Internet Engineering Task Force 103, 8 Nov 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF103-ACE-20181108-1610

Description

ACE meeting session at IETF103
2018/11/08 1610

https://datatracker.ietf.org/meeting/103/proceedings/

A

Good afternoon everyone and welcome to ace you made it to the last session here on Thursday, so happy to see you I'm Roman Genuity, with my co-chair here, Jim.

A

Why don't we get started? It's been a long week, so you've probably seen the note well a number of times. If you have any questions by all means, feel free to ask us. We have an agenda, but before we jump into that we're gonna be passing around the blue sheets. Do we have a jabber scribe and a note-taker? We could rely Pat.

A

Would anyone be willing to be a jabber scribe.

A

Okay, that's great! That's a jabber scribe, much appreciated a team of two and anyone can take minutes for us ether pad or whatever works for you. We need a minute taker.

A

We would greatly appreciate a minute taker. We cannot proceed without a minute taker right.

B

A

On much appreciate, okay, so what you see displayed now is the agenda we roughly sent around the mailing list. We've had to just read: reshuffle kind of some of them to be around two documents: first, that we're working group last call and then the others after that, primarily we're talking about the drafts and then we're gonna talk about adopting, potentially some drafts at the end. Would anyone like to bash this agenda.

A

Okay, I'm not hearing that so, let's proceed forward just to quickly update everyone on where we stand with drafts. We did a working group last call starting in early October in preparation for this meeting, so we knew where we stood with the issues. Those were the four documents that went into our humor last call and that link, if you do reference, is a top-line kind of summary of of the major comments. They came up with all the documents and looking at all the individual presentations that are coming with those drafts.

A

We're gonna talk in a lot more detail about that. We also have a document in Sheppard review kind of with me that I'm working to close the issues from the last working group last call, and there was also a hackathon if someone would like to come to the mic and and say what what happened at the at the hackathon: nothing, okay, so nothing nothing to talk about there. Okay, milestone wise! We haven't changed anything since we last got together.

A

We we're a little behind on some of those, and so when we talk on Oh on a per Draft level in the presentations we're gonna talk through, you know how quickly we can. We can move forward with those documents. So with that we have nothing more. So first up is we're. Gonna talk about the the framework, tech and the documents and ludwig is going to go remote for us with the presentation.

A

So ludecke, are you ready? Yes,.

C

A

Can let me switch to your lights and I will drive for you, okay,.

C

Very much so this is about the draft. We called the framework of alpha and I heat the typo here it's actually about version 16, not about 713, as it says here. That's for me for copy pasting from last meeting about.

A

Excuse me: can we ask the folks modulating the evita crank it down a little bit? It's a little loud sorry about that loop. It was just very loud in the room. No.

C

You're, good thanks, okay, so this is a typo here. It should say: draft off 16, not 13, I carried that over by copy pasting. My template from the last meeting. Sorry for that and the other draft I'm going to mention, is the parameters draft, which is basically split out from version 13 of the framework.

C

Why that was done. I will tell you when we get there, so please next slide major changes from version 13 that you have seen at last ITF meeting to version 16 where we are now is we split out a number of parameters used both for interaction with the token endpoint and the introspection endpoint into a separate draft? That is the parameters. Draft I was just talking about.

C

The reason for this is that there is some parallel work on this stuff in north and I discussed that with chairs, and the proposal was to split out those parameters in a separate document that thought when they figure out how they want to solve that, can obsolete or update or whatever they want without affecting the framework document.

C

So that was the reason why we split those things out in the process of splitting them out. We also had to rename some parameters, namely the audience parameter, which is now called requested audience and certain uses of the confirmation parameter, which are now called requested. Confirmation because were collisions with uses of these parameters in other with other meanings in off. So there is a number of smaller name changes. Nothing major, functional I hope that are documented in these parameters.

C

Draft another largest change, I introduced a content, type co-op content type for ace messages, ace plus Siebel- that is intended for use in co-op, I added registrations, as claims as access token claims for certain things that previously only were parameters.

C

That is the resource, server confirmation and the profile reason for that is that you might have a resource server. That has several well, let's first go through the parameters. Resource server.

C

Conf is a parameter that is used by the authorization server to inform the client about the public key of the resource server, so that the resource server then can authenticate the client, for example, in a DTLS raw public key handshake, and the reason we also added a claim token claim for this parameter was that the resource server might have several might manage several public keys, for example, for different curves so, and this is a way for the authorization server to tell the resource server.

C

This is public key I communicated to the client use that to authenticate. So that's the first one. The second one profile is basically the same argument. You could have a resource server that supports different profiles and this parameter tells the resource, or this claim access token claim tells like the resource server. This is the profile the authorization server has selected that you should use to communicate with the client, so that covers this third bullet.

C

Fourth bullet: we noticed that we had a very old issue that we should explain how the ACE framework works, with refresh tokens and I had contribution from my co-author Eric.

C

Merged into the document to explain how these are used. Basically, we don't expect typically going to be used in constrained scenarios, but there's now text every turn. All that is intended to work next bullet is the added text about using RFC six seven, five zero error codes, so I discovered I hadn't looked at a rough c6, 7 5 zero lately because its bearer tokens, we are mainly looking at proof of possession tokens, but I recently discovered that there are a number of very useful error codes in that document.

C

So I've now added a section that refers to it, and that explains the use of these error codes and defines Seaboard abbreviations for these error codes.

C

And, lastly, we defined a new error code for incompatible request parameters. So, for example, if a client requests an access token for a certain research server and they don't support a proof of possession method, then the authorization server can reply with this new error telling a client there is no compatible way for you and the server to communicate.

C

Okay next slide, please now I have two slides with items that I would like to discuss. Most of them are points that were raised in the working group last call, so let me say two sentences about the working group last call. There have been very good discussions around the documents and I haven't managed to address all these items that were raised.

C

What I did manage is to create issues in the issue trackers on both the framework and the parameters document that hopefully represents the questions raised by the reviewers and I'm planning to address those issues as soon as I.

D

That are not according.

C

To my interpretation, don't have an obvious answer and this is what I wanted to discuss now or want to present now. Hopefully, we will have an in-room discussion, then so, first repeat this question or discussion from the last meeting: the use of loaded abbreviations.

C

So just to summarize what the problem is about four parameters and for certain parameter values in the interactions with the authorization server. We are providing see, board abbreviations now see bar abbreviations, integer abbreviations have a very short representation for values, ranging from I, think minus 23, plus 23, or something like that. So there is a limited number range. You get very compact, abbreviation and numbers creations higher than this number. You get a 2-byte representation in seaboard, so these low digits are.

D

Obviously, very valuable about.

C

Which parameters are frequently enough used that they married such a short, abbreviation I? Think I reached a agreement between me and Mike Jones on that, but I wanted to give you the occasion to raise other opinions. At this point.

C

Anyone who wants to comment on the assignment of low abbreviations and what parameters are frequently enough used that they merit.

C

A

No one's coming up to the mic, yeah.

C

I have a picture of the room, so I can see you not rushing to the mic. Thank you second point. There has been also a discussion related to this abbreviation, so what I have done so far for reasons of making implementations or implementers lives easier? Is that I try to align all the abbreviations? So in order to understand the issue, is we have claims that go into access tokens? We have parameters that go into the requests and response to the token and to the introspection.

C

Endpoint and all these I have tried to align into one single abbreviation in numbers space.

C

There have been discussions now on the mailing list, whether that is a good idea or not, and in the light of these discussions, I've come to the conclusion. That is probably not such a good idea to align both claimed abbreviations and parameter abbreviations, but I wanted to raise that discussion as well. Do we want to have like a unified, abbreviation space for all these things, or do we want to separate claims and protocol parameters?

C

What tests do people have opinions on that.

A

That mic isn't hot.

E

It is on Mike, Jones, Microsoft I believe as discussed on the list that there should be separate numeric spaces for parameters and claims, among other things, that lets you use the small numbers for parameters I.

B

Just gem shot from the floor. I went to the rats both this week and there another group which is once to UC WTS and talking about registry ncwt claims so I think we should probably get a story together on how we think this should work and using the same registry for all seven.

B

A

Them but we lost the mic, could Evi gentleman in the back help with the mic? Please.

A

No good idea: Thank You, Francesca I.

B

Went to the rasp off this week, and that was another group that is talking about, registering CWT claims, so I think we need to develop a common story on how we think all of these claims should be registered as see WTS. In terms of probably the best answer is to say, register a CW claim, which is a map which is identifying the fact that that your claims and then you can have your own registry rather than having everybody fight for the same numbers.

F

So because woman, how many media types do you have me? Yes, there.

C

Is currently the one defined that is s plus C, Boris, Eber, plus a sigh so.

F

How do I know whether something is a CW T or something is a request? Well,.

C

Usually send as a parameter in one of your messages: okay, so there is like a tag that says access, token equals or or so, and then the content of that a parameter. So it says access token and the content of that is the CW t. But that would be the next bullet point. Actually.

F

So I think the important thing is that something that I as a participant in this communication might want to save.

F

To say somebody claimed this and I may need to go to court with it. That probably should be formed as a GWT.

C

I'll go on to the third point, which is a bit about what Carsten just mentioned. There has been any somehow parallel discussion about the use of see WTS as a format for signed protocol messages. So the idea is that, instead of just sending a bunch of sibour parem a map with Ybor parameters in it, you would send a CWT containing your parameters, and this would actually affect a lot whether we have a common registry for parameters and and claims, because then suddenly, your parameters become claims in a CWT.

C

The advantage, as far as I understood, is that certain use cases require sign protocol messages and that CWT would allow you to do that. I.

C

Haven't quite considered if they are any bigger drawbacks. Aside from that, you have to have a common registry now for everything, you could always use the solution that Jim proposed and just like, create another parameter. That is actually forming a namespace for your claims and then you skip all the potential collisions, but that is basically the question. I think that Carsten was racing. Yes, please benkei.

G

Doc I, just you know, thinking about cedar beauties as sign protocol messages. I was gonna point out that in the Acme group they recently changed art Mobb. They introduced a scheme to use shots for sign protocol messages and then later heavily revised. The respect to use that for all protocol messages.

E

Nitrogen Mike Jones has discussed on the list.

E

Use of Johnson sign protocol messages was standardized by Open ID Connect in 2014 and is being standardized by the OAuth working group. Hopefully, to finish this year, it had been stalled over technicalities, but we believe it goes to the RFC editor anytime and given that the ace o r thsee framework is trying to reuse ooofff as much as possible, I think it's very logical to use C WTS as the sign protocol messages just like o auth does, and this is in protection for banking, among other things,.

C

Mike one more second before you leave the Mike I was under the impression that was some contention on the off mailing list. Whether all Oh of protocol messages should be formatted as jobs I seem to recall to read a message where someone said no, no, not for introspection or something like that. Is it really like.

D

C

With token and points introspection, endpoints and where was the other grant endpoint, or is it just for specific interactions that the.

E

Last draft I believe is scoped strictly to the authorization request and Torsten mutters. That has a separate one for responses that also formats them as chats. You could do that for other endpoints, like the introspection endpoint, but I ought isn't doing that at present.

C

Okay, thank you. So my only worry with this is: if we try to align with OAuth, how is that going to delay the working group last call and them publication of the ACE framework, because we are already quite delayed and I'm a bit wary of introducing dependencies on ongoing working off. You.

E

Wouldn't introduce a normative dependency on a.

E

Jar draft the signed request draft you would probably, as an editor, have a non normative reference saying that, when signed a so auth requests are see WTS just like this draft makes sign jot requests, so you wouldn't introduce a delay in progressing the document. Frankly, as editor you've already done most of the work to align the parameter spaces, all you have to do is register it on the new good.

C

That leads us to another point of alignment with ongoing. Oh sorry: go ahead, Jim Jim.

B

Chad I I, don't think we even need the non nor the information of reference to the moment unless we're actually going to document that we are going to carry those messages right now, in the framework.

C

So Jim are you suggesting that this might be a abdon draft that we start and complete at a later point of time that specifies how you, instead of sending the parameters as like a parameter map, you instead put them into a a CWT? Would that be a a workable right.

B

Right at a later day, we could document how the message, the girls from the client to the AAAS, instead of being an application, is passive or would be an application. Cwt.

C

B

C

Yes, get it: okay. Fourth: bullet alignment with ongoing oft work. Well, other alignment with ongoing OAuth work. So we had a discussion during the working group. Last call reviews about our requested audience, parameter versus a parameter called resource defined in draft ITF health resource indicators and my conclusion of the comparing those two is that there is a slight difference or not difference, but the requested audience seems to me to be a bit broader than the resource parameter that is specified in the OAuth draft.

C

So just to give you a quick run through for those who haven't read the resource indicators draft, it defines this new parameter for a token request, with whom client can indicate the location of the resource or service it is trying to access. That is the specification of this resource parameter now. My understanding of how this requested audience is supposed to be used is that you can put anything application specific in it that somehow the resource server can resolve to being part of this audience or not.

C

So you could have like a group identifier or a public key of the resource server or whatever, and this would not necessarily refer to the location of the resource or service that you're trying to scope. Your token to so I see a difference. There Hannes.

H

And Ludwick, that's true, that's indeed a difference, but the reason why we tried to be a little bit more specific in a resource. Id indicators is that it makes the implementation on the resource server simpler, because there's a standardized way on how you do the comparison, because in the other case you have to have some other out-of-band configuration to find out what is them semantics of the stuff that you're actually shopping around? Is that sort of indicating some group of things or is it? Is it like?

H

You said the hash of a public key and so on? So you are essentially doing what some people do today. They munch that overload the scope field and with some opening thingy and- and they basically do artists out-of-band in in a configuration so so that would sort of the approach chosen. A resource indicator makes this comparison more precise.

H

So that's the that's the sort of like there's that obviously bros and cons, but I'm wondering whether you had some specific use cases in mind. That required is sort of more relaxed way of dealing with things that the expense of having an out-of-band configuration approach.

C

Now I, as you know, I am a researcher. I, don't have specific use cases. The question that I found also pretty relevant here, is the difficulty of actually pinpointing the location of a resource with the URL in the constrained space, I mean as I. Think Steffi was it. You mentioned that URLs of of constrained devices can change when they like travel from one network to another, and this makes the use of this resource parameter a bit tricky for me.

C

If you don't have some another way of that, that is static that identifies the resource server, I.

C

Wouldn't I would be at a loss how to give good guidance how to use that in constrained space. If, if we switch to the definition from the resources, yeah.

H

It is yeah, I, see yeah yeah.

I

Good question yeah.

H

B

Do you want to think about it and get back I think.

H

C

Carry on with that discussion next slide, please.

B

Before we go there, there was another one that they were asking about, which the Buddhism was not quite aligned. Was that just a textual difference which.

C

B

Confirmation I think the animation I.

C

Was under the impression that this was pretty well aligned because, basically the same as RFC, 7800 and well I think yeah I think it's a difference of names. I think in the pop key exchange draft is called key and I choose to retain the original name of the claim with cond, but I think that is just cosmetic. We can yeah.

H

I think I changed that I still have to do another update because preparing the slides for the Owens meeting I noticed that I had still had a few glitches in there. So I will do the update, based on um this update, so I think it would be much better.

C

Good I have not a strong opinion on that one. It's just cosmetic, as I said: okay now harnesses looking. No, you know now.

J

C

Tokens for one research server and one client- this was another discussion raised during the working group last call. The situation would be this I'm. A client I have an access token for certain resource server, I'm doing stuff with that access token and then I hit an unauthorized, so I go back to the authorization server and request a new token that gives me those additional rights. Now what what happens?

C

What is supposed to happen at the author is at the resource server if I submit this new token is the new token supposed to amend the older ones so that all the tokens together form the space of my permissions or is every newer tokens for the this client going to overwrite all the older ones, which would then require the authorization server to make the newer tokens like a a collection of all the previous permissions that I have asked for so the the first option is what I currently have implemented and what I think is currently also suggested, not explicitly stated in the draft.

C

The second option that you are tokens override all the ones so in a relation between one client and one resource server you only ever have one active token- has the advantage that it simplifies the management of the tokens a lot at the resource server and since the resource servers are often the constrained devices. I feel that might be a good approach.

C

But I wanted to hear if anyone in the room has any strong feelings about not using this option to where we only have one resource between a resource over one token, between a resource server and a client I'm, not seeing people rushing to the microphone. So if anyone comes.

A

Hold on Jim is coming to the mic. Yeah.

B

It takes a while for me to get in front of the camera. Sorry um I don't have a strong feeling, but there are two comments that I'd like to raise. One is many times the newer token may be for a much shorter lifetime than the older token, which means you're, basically gonna expire. The token sooner the second one is I know that there is a draft in the oauth working group about doing incremental, updates that I haven't actually read through and understood and I'm wondering if that is relevant, yeah.

C

We should definitely have a look at that.

K

So from the jabber Olav says, plus one for option two.

C

Olaf is doing a constrained implementation, so I have a lot of sympathy for his preference for this easier to handle the resource server. He knows how difficult it is to manage option one.

C

Okay, we can carry on that on the mailing list. If anyone comes up with other points for that next, one is a old mechanism I had in the draft for expiration of tokens based on sequence numbers.

C

The background was that at some point we were considering that there might be constrained devices that do not have a internal clock and therefore no means of ever expiring a talk so I at that point added a description of a mechanism whereby, for every token, that is issued for a specific resource server, the authorization server would add a sequence number to that token, and then the research server after receiving tokens with a certain sequence number would start to expire tokens with a much lower sequence number.

C

Obviously, this is not extremely resilient against attacks that suppress the submission of new tokens and so on, but it was meant as the best effort like if you don't have any means of measuring time. This is the best you could do. This has generated a lot of discussion, since obviously it is not very secure against any kinds of attacks that try to prevent the expiry of the tokens.

C

So my feeling at this moment is since this is a very improbable use case where the following discussions showed that, like almost every device should at least have an internal clock with some wall clock time so that they could do an expiration based on so on so many seconds from when you receive this token, this mechanism seems obsolete. So my suggestion would be to remove that if no one violently disagrees at this point, I don't see no.

A

One who's running up to the mic running.

C

Up great last point, symmetric, conf confirmation, keys and multi resource server audiences.

C

So the the case that I had in the document was that imagine an access token issued to a group of resource service identified by a certain audience and that where the proof of possession key is a symmetric key embedded in the token and I was arguing that this should not be done because then the first resource server, who gets this token, can impersonate the client towards any other. Member of this audience now, Jim has raised some valid concerns that this might actually still be necessary in some multicast use.

C

Cases and I wanted to open up this discussion because I'm I am not sure which is the best way to go here. Should we recommend against using symmetric confirmation keys in case your audience, is more than one resource server or are they valid use cases where we need to be able to do that.

B

Jim shot after thinking about this I think that we I would be perfectly happy to say we stay as should not for now, and we wait for the use case to show up and fix documents at that point, if needed. Just.

G

Been catered basically the same thing, it would make me very uncomfortable to allow it, so we need to have a good use case of mind.

C

Strong enough or no it should not, or should we say what is it the stronger one I'm not allowed or not must.

A

C

G

Think it would depend on the surrounding text. Okay,.

C

Let's do that on the mailing list, I think I've already over my speaking time. This was my next last slide. So next slide, please.

C

So my next steps, I'm planning to address the working group last call comments and the results of this discussion as they manifest themselves on the mailing lists and in the minutes and for anyone who wants to follow the progress you can see the issues on the issue tracker on the github of the working group I've tried to capture all the working group last call comments, except for minor editorial comments, which I'm fixing as I go. So if you want to see that I have genuinely captured your working group last call comments.

C

Please have a look at the issue list and, if there's anything wrong there, then please correct me. Thank you very much. That was my presentation. A lot.

B

Of it before you go, can you give me a rough idea of when you think you're gonna publish the next version I.

C

Have project the project that is funding my ITF work ending right now, so I will be very busy during November and December. So unless I get some substantial help from my co-authors, this might take a while I mean I can, of course, within a few hours here and there. But this is like a final review of a three year project and I'm responsible for the whole Swedish consortium, which is four companies, so I'm going to be pretty busy with that.

A

So January, oh no.

C

No, no, no sorry! The final review meeting is in in in first half of December, so like second half of December up to Christmas, I'm hoping to be able to squeeze in enough to address. All of the comments will of course start addressing comments as soon as I can in a second squeeze in time. But sadly, the agenda has been filling up pretty quickly.

A

Perfect thanks: okay, next up on the agenda, Gordon is gonna talk to us about the DTLS profile and the clicker does not work. So please so.

I

This is a DTLS profile and this slicer prepared by Olaf or unfortunately has a sore throat. So he can't speak so I'm going to click through these slides as best as I can next slide. Please yeah. The current version is a five. Since version 3 there was not so much content change. There was an improved readability, cleanup of examples and looking at Cosi structures, we got a really good working group last call review by Jim and that's there was an answer where we did. Some of the some of the changes have already implemented.

I

Some are in the answer as proposal. So unless you have any objections, those would also be implemented, and then there are four issues we'd like to speak about here. Next like this, so the first comment was about an example where the this is so. This is the symmetric key case and there is a a response on the top post token.

I

So the AES sends a information to the client about what key to use to communicate with the resource server, and this didn't include a key identifier, which means that we need to which is basically a handle for updating the good for updating the privileges. So the proposal here is that we actually write that this. This should be included to simplify for for updating the privileges. Yeah honestly.

H

So this is so it's the client supposed to send a key ID to the authorization server or is it the other way around that the authorization server provides a key ID back to the client? Yes,.

I

It's going back, the AES should advocating, but.

H

The AES can provide that key ID already since he's sending a key it that comes along with a key idea. Exactly I was just missing.

B

James actually I think this whole issue has been overtaken by events in there. Instead of using the mechanism we were looking at, we should be actually be using right, refresh tokens not sitting up the key, a key all right.

B

In that case, it's obsolete.

I

Okay, so I don't know if I need to go to the related question Dan, but basically to answer the red light. The question is: do we need a special treatment for our play case and I would assume you would use this same mechanism there? Okay, great next, like this part, this comment, I'd actually didn't really understand. So, let's see if I can sort it out. Basically the response again. This is the same type of response.

I

It's a cosa key coming from the AES to the client, but there was a question about the length of the K length. Of the key is what the kid is going to be used. So if, if the client is offering both a hundred twenty-eight, I and aes-256, what length should be used here of the key? And that's someone has a good answer. There, I'm not really sure I understand the question myself.

H

So in the in so I, don't remember the that jwk answer to this in there was actually a a Gers, my D, which provides you exactly that information. So you would include so the example above then also include the address my D okay.

I

Fair enough, yes,.

H

And I would assume that the cosy key has the same information India. Yes,.

I

H

It doesn't, then that would be a oversight. Okay,.

I

That was actually the alternative that was most likely. Okay. Great. Can we have a stiff on that as well? Next slide, please! Oh!

I

This isn't! This is an easy one. Basically, if there is an error in terms of authorization within the TLS session, have asked for a resource that you are not authorized to do or do something you're not authorized to do. That should not be non-fatal. That should be a non fatal error from the others point of view. So that's I think that we all agree on that. No comments on that. Okay, that's readin! Next and final comment is oh, so this is about the key derivation. So we have three methods.

I

Basically, either you provide to the resource server, a public key or you provide a symmetric key or you provide a salt, and the purpose of the salt is to use the shared key between the a s and RS to derive a key. That's really efficient, because the salt could be very compact, and the point is now: how should the conf look like?

I

Should it look like this? It I mean it used to be a cosa key, which was absolutely wrong. That was the problem statement here. This is that was the first proposal and then I think, as you pointed out, is there a middle layer missing here and I? Think that's that's right, so this should actually be the conf should be and I'm having identifiers and that identify you should in turn contain the salt in these parameters, but these parameters.

I

So that's the proposal to introduce something like ace, salt and that contains p-type, derivation algorithm and the actual salt.

B

Jim shot I, don't even remember this as being in the version. I reviewed and I haven't the foggiest idea. What this thing's is doing. Sorry.

I

We have the focused idea: what I don't.

B

Know what I don't know what this is I, don't know what problem this is trying to solve. Okay,.

I

So that was the case of having a really compact access token and not not actually transporting a key, but just transporting a salt, and you use the key shared between the a s and the RS and the algorithm here to derive the key you're going to use. So this salt only goes to the RS, whereas the cute Alliant is provided with the key.

H

Whether that's a good idea, because we are now adding another mechanism to it- another possibility that that has to be implemented and what I'm so I've been working on the on the slides for the for the oil session and they. Obviously it would be nice if the JWT of our JSON based encoding matches somehow the CWD encoding from the functionality point of view, and currently we have already a couple of different mechanisms. So you, in addition to the key transport with for symmetric here than adding a sort of a key derivation, a bridge I mean.

I

This is definitely the case for six 60s, for example, where they really have a hard time of fitting acid CWT. Doesn't really I've been really hard to fit into one frame of their transport, so this is typically use case for them to implement the the salt instead of anonymity, but.

H

I'm sure they have also an adaptation layer, so is that sort of sobbing there there use case I mean.

I

If you talk to them about multiple fragments versus single fragment, I'm sure you will get the same answer as I get basically can be squeezed this into one fragment. So it's a constrained use case. I, don't see so.

K

Look from jabber: it also has the advantage that an attacker that learns, the content of the CNF claim, cannot derive the key sure.

H

But the assumption is that there's confidentiality protection between the client in the ears anyway Innes, so so in that sense, you shouldn't get that it.

I

Actually depends whether you use I mean yes this. This would typically be encrypted, but if you use the post its authorization info, it could be, it doesn't only has to be integrity, protected.

B

Right they yeah with his jump shot. This is inside the CW k and CWT would normally be encrypted. Okay I feel uncomfortable about this, because I'm worried about possible, with the keys being protected correctly you're, adding a key derivation based upon it I'm on a secret which is supposed to do one thing to do something else and I'm, just not too happy about that. I.

I

Think the intention here was not to use the same key I mean to use the derived key so that things shouldn't be a problem from the point of view of I mean it totally agree with. You should not reuse. The same key I need to check that whether that is already included in the draft or not I can't remember that.

I

So what was that? The main concern, basically, that we have a? Are you seeing a yeah? Okay.

I

So but the question here was actually not this: this was not. The question was actually. How would this CNF look like not whether this method should be used or not, so that seems like yeah.

H

Kind of a late discussion.

I

H

Currently so this is another, so we at the moment, at least from the JSON based version, there's only the key container or the cheetah, the che w/e, because there's an encrypted version or non encrypted version, and so here, how do you then out of this I assume you would want to have? Maybe do you only want one version, the unencrypted or do you want to have an encrypted version as well? No encrypted version yeah.

I

I mean that was slow. This comment, whether we should choose it unencrypted ID. This could very well be encrypted. There's no problem with that. Doesn't.

H

I

H

Then there's you need to have another wrap around it. This.

I

Is this I mean if this had been a key, you would send the key in a jwe. If this is assault, you sent assault in a jwe, the cyclist same procedure, but.

H

The way how the structure looked like in a response parameter, there was a CNF claim that was sent from the clock from the heirs to the client sunshine by the client, and so how it looked like previously was a CNF inside had either the encrypted version or the key container the cozy key in this case, or the che EE key yeah. You should have this in a cozy key, but.

I

We realize that that's not the right type of container, so it's supposed to define a known container for this, like I mean so you having. So what is the analogy? What do we have in the Oscar profiles? We have an Oscar security context which contains the parameters needed for Oscar. Now we have some other name of a I can't CNF, which contains the parameters needed for deriving the key with the salt. I, don't see a big difference, no.

H

It's just wondering like how it would look like.

B

So I mean what you just described says in in here and in your example, after you're missing a layer you should have CNF, yes contains a KDF derived which contains those three exactly.

I

And reading your review comments, it was actually is there a missing layer on this one and that's I'd. Certainly agree wit just want to confirm that here.

I

Okay, that was the last time. Thank you very much. Okay,.

A

Thanks for yourselves, stepping in also do the presentation do we have a sense for when the updates could be made.

I

So I hope all of them mostly but I think this is certainly this year, so it should be December December, that's if I'm gonna be involved. It needs to this December, but all of my to it quick I, don't know. Okay,.

A

January got it all right: no I have to January it's the holidays. Let's be realistic. Yeah.

J

A

Yeah, that's right all right! Let me get your slides up for insurance and.

A

Again, there's no clicker, it doesn't work. So just tell me next, like this: okay.

K

So, oscar profile of face, we are at version 5 that was submitted two days ago, something like that. So next, so the status is being updated. According to the working group mescal review, we only got review comments from jim.

K

This is a list of issues that were in the github issue, tracker and we've taken care of those and the update deals with all of this, but I still want to mention too, and then there is one open point that has not been dealt with that I'd like to get the working group advice on our opinion next, so the first, the first request from Jim was to add the section on discarding a security context.

K

I now had added this, and so the result is that the client must discard the security context associated with the NRS when either the sequence number space and the access access token associated with the context expires. The client receives a number of unauthorized responses to Oscar requests. The exact number is not specified here or when.

K

The client creates a new security context from an old non expired token, and the RS must discard the security context when again, the sequence number space ends or when the access token associated with the context expires. So my question would be, if you see any other situation where either the client the server have to discard the security context.

K

Please let me know.

K

Yeah, so maybe you can take a look at this if you have anything just mail in the mailing list next, so another thing that was requested by Jim and has been requested a couple of times. It's not is to not use a kasi key structure to transport.

K

The oscar security context, input parameters and these parameters are master secret salt identifiers, so I implemented this in this current version and I use oscar security context, structure that can it can either be Jason or C bar, so I give define a set of parameters and I say that I give an example for an escort security context in Jason you can see and I also use CDL to define it in C bar and it's a two parameter.

K

C is the same so that required a lot of added text, but the content is is quite small, but so there is a registry creation, which is the registry for registering these parameters in the Oscar security context and I have put in expert review required right now. So if you have you think this is not the right guideline for for registering than or policy.

K

Let me know, then: I also added the parameters: registration, the CWT and jot registration of the oscar security context structure and also the guidelines which were taken from a cozy which might be probably improved so right now, I do not say anything about so it's it's expert review required, but it's also like ITF or specification required for all the ranges of parameters, but I, don't say anything about for for this parameters to be created that will be linked to a score. Maybe this is also something to think about so yeah. You can think about this.

K

Let me know if you have any comments next and now, I want to talk about the one issue left, so this also came up from James review the issue.

K

The assumptions we have in this document is that the client and the RS can forget the security context and also they can forget the tokens and they do not keep track of all the tokens as received, and another assumption is that the client can get an old non expired token from das if it forgets it next, what this was the previous protocol overview, so this was from version 2. The last version before all these updates, and what happens is that we get the access token.

K

It contains a set of input parameters that is posted to the RS and then the security context, derivation happens and the security context derived from it is used for Oscar next.

K

So that when we had this issue of client and resource server losing security context, there was a problem with reusing nonces so so and talk about a EAD nonces.

K

So we had this proposal in so this is in the version 0 5 and this added adds to non says 1 created from the resource server and send to the client the other from the client to the server, and this would be input to the security context derivation, and this will avoid the use of a denounces and keys on both sides. Next, so first of all, I wanted to motivate why we are using these nonsense.

K

So the issue is: if the reason server loses its security context, then the see the client would repost the same token, assuming it's not expired, and then an attacker can replay an old Oscar request that use that security context and that would provoke reuse of nonces on the server side. So next it's easier with a picture.

K

So this this is exactly what I just said. So the resource server goes down, loses a security context, the client retrieve or resends the token. Maybe it still has it and the resource server read, arrives the security context, and you can see that the worsen an attacker can replay an old request with an AED nonce, let's say with value a and the resource server would then use that aad nonce to encrypt the on the response. So there would be a different message from the previous one. Next.

K

To solve this problem, we have added this first nonce, which is the one from the RS to the client and in thanks today. This then the server will not reuse the same nonce, because it will create a different security context. Every time it goes down, basically so next to motivate the present of the client nonce or the need for the client nonce. This is the issue. The client loses its security context and also its token.

K

Then it gets a token posted to the resource server and an own path attack replay an OLE message from the resource server to the client that contains an old nonce and one. So it replaces these first nonce that we talked about before and that will lead to reuse of nonsense on the client side so with the picture next.

K

So this is so in the first Oscar request and response the client, the resource server, using one security context. That was the right we nonce and one. Then the client looses its security context. It gets the token which is the same before and post is talking to the resource server. The resource service sends another nonce, but an attacker stops a message and replaces it with old message, which is with the nonce and one.

K

So this will end up with the client deriving the same security context, and then we, you see the security context for for request next.

K

So to solve this, we use the D nonce, and so because of these security issues, we consider that using nonces cannot be optional. So it's not mandatory in the in the draft and the question that I have. First of all, if you see any problem with that, of course, please go to the mic and say so. Otherwise.

K

The question to the working group is: how do we transport these nonces and include them in the oscar security context? Derivation? So.

E

K

The first proposal, which is the one that is currently in the draft, is to send the nonce around resource server to the client in the payload of the one created response and then send the second nonce, together with the first nonce in the Oscar request.

K

So you can see that's the part in red, so this has the con that the resource server derives the security context when receiving an unknow key ID context, but I'm not sure that we can avoid that even in the other cases, and also we send the both denounces, when only n2 is needed really from the client to the resource server. The Prophet is proposal is that we don't use the salt parameter in the security context and we leave that for the application to define it next.

K

So the next proposal is, we use one nonce as a salt, one nonce as an ID context.

K

So the pro of this is almost exactly the same thing, but the the pro is that we only need to send and to endure in the request from the client to the resource, server and the conduct. We also use the salt. So an application cannot use that for something else.

K

Next and then the final proposal, which is the one that we prefer we think is the cleanest one- is to actually the the client to the resource of a token be included in the payload of the post, token to the resource server and, and then the resource will reply with the nonce in the payload of the 201 created, and then these two concatenated will be put in the ID context and it will be included in the key derivation.

K

So I think this is better because it's it you don't need to send nonsense in Oscar messages. You do that before the con or the the biggest problem would be that this requires changes in ACE framework, so ludwig.

K

If you have opinions on that, because to be able to do this, we need to use the content format, application a /, C bar in the post of info request to the resource server which right now it's just it doesn't have a content format in basically, the payload is the token directly, and what we want to do is to be able to send a seaborne map as a tailored with the access token and the nonce together.

K

So look Vic or anybody else do you have opinions on that.

K

Is there anything in jeopardy.

K

B

Craig, wake up.

D

A

All right, Luke.

L

We could have pushed the button too, because he's all remote he likes proposal, three I think proposal. Three, we can use content format a spicy bar while using a spa CWT when we send a token directly would need to define the 8 + CW TV content format. So I guess I need a new content format. So why is right.

C

L

C

I actually typed that out of reflex and then remembered that I could just use me. Tech, oh yeah, so my I do like this third proposal and I think we need to define a new content type anyway for sending CW T's in ace directly. So that would be this H +, CW TN and it to me makes sense to define that as a content and then profiles that use the info endpoint in a way that they directly send an access token.

C

They can use this content type ace, +, CW, T and the score profiles could use the content type ace, + C bar indicating that there is a map structure in the in the post, payload that contains the access token and other parameters. So.

K

C

K

But also right now, in the ACE framework, the content format, application s, + C bar is only defined for client, a yes and a yes client. It's not know where it said that this can be used between client and resource server and vice versa. So I, that's.

C

The oversight that should be okay.

K

C

Create an issue as soon as we come out of the meeting. Yes.

K

G

Benkei duck and it's the end of the week, so I feel like I'm, just seeing us for the first time, but you're, apparently from the information flow and like the crypto sense of the way you you transmit and use the nonces proposal. Three is best sorry.

K

I didn't get the last part.

G

In just in terms of the the cryptographic, use and transmission of the nonsense proposal, three is is the best okay.

M

F

Last moment I'm very confused about what you just said about linear types. Maybe we should stop here and say: I'm, just very confused, but plus CWT doesn't exist and if you want to send us your tea, we have a CWC India type. So why do we need another one? So.

K

Maybe you're referring to what Ludwig said, because what I want define in the eyes framework is the the ace plus C bore, because I want to send a C bore map that contains a nonce and a CWT. So that would be an ace plus C bar and then Ludwig was saying that he wants to define a splash CWT to send just CWT, not in a map and then, if you're saying a CWT exists already, then that's a comment for Ludwig, I guess and if he wants to reply to that.

F

E

Like John's wearing my Watson job context had the in the seconds working group, they've finished the security event, token draft, which was the first to want to use a +, JWT media type suffix, and it did create that and register it. It was used in a right for, like second vent plus JWT or something so it wouldn't be unheard of at all for a draft including one: that's not the seat of 80 draft which didn't define the suffix to do so.

E

If you think you need it and you could copy the text from the security event took and draft, because the sin taxes of won't keep that just copy at me, cut and paste. Okay,.

K

So I guess this is still related to discussion with Carson and Ludwig about GWT content format, but I heard people saying they like proposal three, which is great. That's also what we prefer and then I have one final question. Next.

K

Which is about, should we use the same content format from for the 201 created response from the resource server, and can we use to register parameter nonce to send and one?

K

So if you can go back one one slide, so basically we have this 201 created and what we will, what I was thinking could be also useful is to use content format same as as the others, a splashy bore and and then send the Seaboard map with a nonce and one, and also- and this relates also to previous previous question- can we use these nonce, so I think a question for Ludwig?

K

First, there is a registered nonce that is sent from the AES to see it has a seaborne label and I was wondering if we can use that for also the post of info request and the 201 created response.

B

Kirsten, can you answer the the Seaboard question? Is there any problems with using a content type with a creative once.

B

You expose us, I mean.

K

Created content, configurated has payload, so why wouldn't it have content, Furman, I.

C

Don't see a problem with that.

C

F

Long as the media type doesn't start to mean something completely different in a true one, as in another place, no there's no problem with it. Okay,.

K

Still the question for Ludwig stays: if, because right now, this nonce is registered only for this AES to client response can we can we make it more general and use it also for other requests and responses? Yeah, okay, great so that's it I think we answered all older so.

A

What do you think your scheduling is so.

K

We only we only have this proposal to include and and get it right, probably get. Some reviews will be very useful, so hopefully I can do this in the next two weeks and then I can upload a new version and I can get three views of it. So.

A

We can start in early December. Yes, thank you. Okay! Next, on the agenda, Mike, you were gonna talk about four obsession.

A

Again, no work and clicker so just placing an accident not.

E

Mini Mike Jones Microsoft I wanted to update you on the progress we've made on the proof of possession key cymatics receiver web tokens draft next.

E

So we've already been talking about this in the meeting, but just as a refresher, the seed of it he pops back, is the Seaboard equivalent or the CWT equivalent of the JSON web token pop, which is RFC 7800 CWT as a refresher became an RFC in May C to D pop is also required for a number of aspects, including the ace o auth authorization Draft.

E

So there is a normative dependency on that we conducted working group last call after ITF 101. We published draft a 3 that addressed most of the comments we published draft of 4 earlier this week to attempt to address those that Roman had thankfully identified that we as the editors had missed. So we took a stab at doing that. Almost all of those were gems roman cleared. His gem said that there was one major thing that we missed, which is during Montreal gem.

E

It suggested text on the list to effectively give people warnings about security things you have to think about if you're, using a key ideas, the confirmation method and the editors myself, and could it's based on getting that in I? Read that earlier today and modulo, you know cleaning up nits in the text I'm happy, including that so expect a new draft with more security statements about what can possibly go wrong if you use a key ID from our ever paranoid gym, which he laughs and smiles shortly.

E

E

What did we change? You know, for we remove two sentences that people found confusing and we're actually unnecessary for the exposition. We corrected some type descriptions in Vienna and there's an active thread on the mailing list that you may have seen this week. That does describe their responses in detail and again thanks to Roman for putting the list together to help us out and finishing next.

E

So we believe that it's probably time for a shepherd review, which can start in parallel with us, adding a few paragraphs that Jim is already thankfully written for us. Roman I believe you that absolutely I'm.

A

The Shepherd and I have part of the write-up ready, so I'm ready for the dash of Ivan I'm having a press board very good.

E

Next there, if that may be the last one any questions or discussion. Thank you for all the useful comments during working group last call.

A

My usual question: oh five, when they think I.

E

May be able to turn that out tomorrow, Hubble we have this friday for side meetings and I only have one that's in the afternoon. So to the extent I can get stuff off my plate. Great, that's.

A

Wonderful. Thank you for that update.

J

A

We have the nice background music, so next up Michael is going to talk to us about coop nest.

A

Sure kept the music as you walk up yeah.

L

Okay, good where's, the pink circle, pink, X I. Guess we're not doing that here hi. So my name's Michael Richardson. This is the coop est document deals with constrained broke vouchers. You know what I kind of screwed up the title: didn't I yeah.

A

Cut some I copy.

L

And pasted too too much anyway. It's just a book co-op est! It's not about that other stuff! Next slide, please so major things in O, six remove the changelog to the front. So that makes a lot of.

L

Difference: it's it's been unclear, some of us whether we really need to do discovery. We have resource type values, early allocated, chai ant from I Anna, and we made clear what were compulsory and optional endpoints.

L

We don't need one of the code points because it's in the content, the multi-part content type next slide. Please I think the most exciting thing is that we have had a group of people from well three groups, but four companies, because one has a server only and one has a client only who have been doing virtual interrupts testing every Tuesday. For me it's 10:00 a.m. but it's 1500 UTC they even tested last week without me, and this week I decided to go to sleep instead of hanging out with them at 10:00 p.m.

L

and they went continued on. So that's great, so we've been doing this online. If you have code you want to test, then you just need a public IP. If you're and if you're, not, then you can just do it from your laptop behind six layers of NAT, I, suppose the biggest problems we had the first meeting. You know we were just basically well. Do you need to trust anchor? Are you promiscuous? Will you renew any certificate? Do you trust the server that you're going to talk to?

L

Are you a client and we had a conversations back and forth and different people at different settings and different assumptions?

L

We need a mailing list for this, because it was easier than you're trying to figure out what the CC list is. It won't last very long and continuing on I would say there hasn't been a lot of feedback. We things have once we figured out how to operate our own software. Things mostly worked. I think we are now at the point where and know what the status is from this week, but last week it was WOW that CSR was really cool. It looks right and I wonder why my software didn't like it kind of thing.

L

So that's not in the realm of things that are specific in this document, but rather just general interoperability, stuff of PKK's. So that's a really positive next slide, I think that might be even it yeah. So we think there are no issues.

L

One of the things we are concerned about is that ESD co-op is not a protocol really that stands on its own. It's either a building block for other protocols such as burski or some other things that people are doing. It is useful for entities that wish to renew certificates in the field for manufacturers that are shipping devices with pre-built anchors for their customers, so in other words, the device is not generic, but rather is a specific device for specific customer. It's quite common in the metering industry.

L

You sell a customer, you know a hundred thousand meters and you give them the firmware. They want, okay, that with the trust anchors that they expect. So that's pretty that's a kind of a it's, a very, very clear, vertical and- and this is the kind of thing they they want to do right, so we're a little bit concerned that it's not going to survive.

L

Wide-Spread iesg comments without some use cases to understand why it's secure and not. At the same time, we kind of feel that the use case detailing use cases may be a rathole of boiling oceans here. So Hannes I love your opinions on this.

H

Yeah, so our use case is in the context of device management for IOT yeah.

N

I, like reflected.

H

Into him and I think that's also true for a number of companies here, yeah so.

L

So do you think we should include that in a one-paragraph somewheres to say here's a use case, or do you think it's opening up a door of we shouldn't.

H

I'm, obviously it's not a secret like we are very vocal, but those use cases, and so uh so it's Ericsson and Nokia and 12 is so so it's not a right something that should be shocking. You know no.

L

It's not shocking, it's just it's just it's very much vertical right and because it because you.

H

Cannot really it's cross like we use that emilich, mostly in the industrial space, but it in very broad sectors like for for energy, for transportation,.

L

For etc, what I'm trying to say is that it's it's between the vendor and their customer and by up I mean it's vertical, and it's tends not to be between two two systems that the customer has arbitrarily purchased or randomly purchased from different vendors. Okay. This is not internet level kind of interoperability, any web browser to any server right, because the trust anchors just don't exist, generically in a product right, if you don't put the trust anchors in it, doesn't work, of course yeah okay, so we provision does trust anchors during manufacturing.

L

Right, I, understand that and therefore that device becomes specific to a specific, maybe even customer.

B

Jim shot from the floor I'm a little bit lost, so st is secured by some form of TLS correct. So what you are actually talking about here is not how the channel is secured, but how you establish trust in the channel. Yes, correct, okay, that I, don't think, is a huge issue. That's.

L

Good, do you think we have to add any text to say how this happens? No good I prefer to say nothing than to say something that is winds up being something you're. Gonna have people who say no no, but but what about this case? What about this case? You've excluded something Zack, you're, happy I, see nods from Mike Jones as well.

N

Christian well I mean speaking as someone was being reviewing the use of whiskey in a similar.

D

N

The diplomacy book is a trade off so.

H

N

A trade off that allows you to do a configuration of devices that you have bought from a manufacturer, mm-hmm and so effective leader. The use case is pretty much. What you described is that someone buys a hundred, widget or manufacturer manufacturer, takes a hot lead on differentiated widgets form the warehouse and shipped up to the guy guy unpacked them, and at that moment magic happened because they quoted manufacturer side and say: oh, these are the one you bought. I put the right software on them.

N

I also find use case yeah, and you should have we described it in about that level of detail. So people understand what you're doing. The reason why people are queasy is that it seems that if then, the guys who bought the device wants to resell them right, but there is.

L

N

Is a dependency at that point, yeah.

L

N

The manufacturer kind of agreeing and- and that's that's where the the crux is right.

L

Right, but this this protocol that we're talking about right now doesn't have any of that magic. This is this is protocol right now with this. This document is, there is a client, it has a list of owners or an owner, and there is an owner that has a list of manufacturers that they are accepting and that's statically configured period, there's no magic, there's no other stuff, that's happening so, but you can also use this protocol later on as part of some magic. But that's not that's not this document on itself, hey.

N

Yeah but I mean it basically, the the is you at all, as you said that you fear is based on what I described. So if you alleviate that fear, somehow it'll be nice right.

L

That's why I'm asking do we need to be? Do we need to have a use case part here that narrows.

H

The scope enough, so there's no argument, I, don't think I I wouldn't worry about comments from the ihe that haven't even happened yet go ahead like this is this document is defining on how to carry est over co-op yep. We have another earlier document that said how to carry ESD over HTTP. It didn't your arc about these other use cases either. Why would that be a problem now I agree with you. That's why.

L

I think it's if, if est was, could be published, then this is good. I I'm trying to avoid text and work that I think will could be unending. That's all been.

G

Connect I mean yes, Christian, that's one potential thing that is, she could be concerned about, but I think Michael was thinking more about the sense of well I'm. Putting in this use case that I'm describing, but the use case would only be for your one manufacturers devices talking to the same manufacturers devices and like that's, not a right.

G

That's another thing where you need the interoperability that we comes by ATF to get right, and so by not mentioning that use case that is sort of a local use case or a local interact local to the manufacturer, interaction use case. You avoid the question right.

G

L

Not exactly locally manufactured, but the point is that manufacturer arranges the trust appropriate for the scenario.

G

You know the is I. The concern is that the highest, you would say, look at this and say the only use case. You're documenting is not a case that we need. So why do we need to care about this right? The.

N

Est doesn't say with whom you're onboarding, crap, okay and and the real crime is not so much I mean that the discussion we had relative to brewski is that booze he's extending EST into a three party protocol instead of a two party protocol. As long as you have a two party protocol, I can't see the e. This is the two party protocol.

L

Constraint yeah, so if you're happy then Christian whatever and we're all I think we're all happy and I think that's last night and Jim massive was ready for a last call earlier in Monday and I said: I would note by Thursday and I'm pretty sure about this point already by that the last call does.

A

Anyone disagree that it's ready for last call.

L

Okay, so so Peter watt has some edits to make good okay, so.

A

Next question: Peter.

L

Will finish the edits by yes, yeah.

A

That's the next question: when when could we see those that aspire.

L

That's what I heard and.

A

Then we then we're ready to go. Ask off with that draft, so.

L

That would be what December, 1 or December 2 3 p.m.

A

L

A

Let's thank you.

A

Okay, thanks, okay, last up on our agenda is we were going to talk about adoption kinds of things.

D

A

The Gator trackers as tired as we are.

B

Okay, so we have three drafts related to group communications. These drafts have been presented several times in previous meetings, but the chairs have been saying: we don't want to adopt any work until we actually see some documents go into working group. Last call: we've seen documents go into working group last call.

A

B

We are very excited, make it to make ends life more difficult before too long. So, basically there's this three documents. The first is has to do with, let's say right, so the first document it has to do with how do we do Keene in in the a so off profile for group communications? So there's basically three questions. We're gonna ask: are you in mouth like two questions? Well, three questions. Do you think it's worthwhile to do? Are you willing to review? Are you thinking about potentially implementing so well?

B

It'll, basically go through that with each of these three drops, then, do you want to stand up and listen to an Seska, so.

K

Before we go for that call for the second document pub/sub as an author I wanted to say that this was not updated lately, and this is not being prioritized by the authors, also because of the pub/sub work being a bit delayed in core, so yeah less priorities.

M

For is that code, for we should not talk about it for adoption.

K

That's your decision, but yeah.

A

Let's start with the top start.

B

With the top one, how many of you believe that we should be adopting this work? It's worthwhile to do.

B

How many of you do not believe it's worthwhile to do.

B

How many of you have no idea.

K

So there is plus two humps in the chopper 4 for work being adopted 3. Actually how.

B

Many people are willing to review this document. Stick your hand up Peter re.

B

K

Ludwig and Wouter in the chopper.

I

About six people.

A

B

Think think that they might actually implement this ok, so we got a couple. People.

K

M

B

So the next one up is the pub/sub profile draft. Well,.

A

I mean actually before we do, that I mean what do we do with that, so there's interest, but that's not. Are we going to adopt it? Well.

B

Basically, it's okay, my mice, my stand on this is basically the chairs. In the end, the ad talked about it and then we send to the list.

A

F

Are we done with okay on the pops up profile? I would like to repeat my comment that it's not really about pops up. It's about communication with multiple senders and multiple receivers, of which pops up is one instance, so I'm not sure that the fact that pops up document in the car is not moving forward very fast. It's keeping us from making use of this.

B

Yeah I think author lack of interest Matt okay, so how many people believe that this is worth work worth doing? I'm pleased.

B

How many people believe is something we should not be doing hum, please how many people have no idea.

K

One more hum for doing it.

B

The people who that the virus, the group seem to be the people who have no idea. Does anyone want to stand up and say what they would like to hear to have a better idea.

I

So I do have an idea so, but I just want to say that I think this is important work but I think it's it's not phase 3b. Yet with things going on in core and other things, it doesn't be prioritized. So, let's come back to this question about adoption at a later meeting. I think why I suggested.

B

Let's go ahead and finish this: if you, if you, if you are willing to review it, raise your hand.

A

B

Implementation.

B

That's a bit more of a problem: I see no one yeah, okay, the key management for us or groups. Can you give me a 30-second summary of this document because I don't think I can at the moment.

K

So there was one more hand for review Ludwig.

O

Market-Lock arise, it's an incarnation of the first one, so using the model and message format of the first draft to describe exactly how to do key provisioning and group working to enable communication with Oh score s per group, Oh score.

B

B

How many you think this is worth work work worth doing.

B

How many believe this is not worth doing.

B

How many of you have no idea.

K

Three more hums for for doing it. If.

B

You're willing to review raise your hand, please see three I see ya and I similar. The way goes to, if you would think about implementing this sorry.

K

One more more willing to review in the chopper Recon about.

A

Five and I saw two implementers, yes, I said.

B

A

B

So basically, the chairs will try to get together with bin talk about it and will actually send this to the mailing list, since everything life is actually needs to occur on the mailing list,.

A

That's great, okay! Alright, thank you for all of that feedback and helping us determine and again thanks kinda for the patience with the sequencing as we are waiting for the original documents go working group last call before we can start thinking about this additional slate of work comment. Yes, hi.

P

Karen um one more comment on the Buffs of profile: I understand that it's lower priority than the other two, but still it's pretty much the normative reference, the reference for pops, a broker which we are planning to finish, it's being slower than we expected about our planet Venus still, so it would be unfortunate if that were could be pending on this government for a long time so eventually being going to product. That would be, you know a little soon would be nice re.

B

I've been hearing that about tubs and never a year and a half I know I'll believe it. When I actually see a substantial document.

B

P

I think we have a substantial document and, yes, we have some of your review coming still to be addressed, but it's not something that is started just recently. We are actually our implementations and relatively stable document. We have to figure out some aspects on that how it does relate to some other more recent work. That's why we didn't do an update for for decide here. um Otherwise, it's pretty stable, stable thing and we should be able to push it through the finish line relatively soon. Okay,.

A

Ludwick was next and then it'll be your honest lyric. The floor is yours, hello,.

C

We have a while ago also a profile presented for using ace with mqtt. I would like to ask if there is any interest on pursuing that work, because my impression was that MQTT is a protocol that is pretty commonly used in the sensor networks area. So I have this impression that this might be useful. I, don't know if the authors of that draft are participating remotely or in person.

B

The authors of that draft right now I have basically well the last thing I heard from them was they were basically working it on it and they weren't actually ready to go into a working group status for various reasons.

H

Now, how did son one thing I was wondering what what we can do about this at least quotes problem. Is it would be nice to actually see more product implementation of the work we're doing in this group? I see a lot of prototype implementations. That's great running code is great, but we need some deployment right, and so how do? How do we get there? It's one thing to push the documents too quickly, but kind of quickly, but you know you know what I'm hinting to.

F

F

If I had money to implement the product.

F

Would I invest in something where I don't know whether the is G is going to hold it up for two or four three years? We need to push these documents through and then we will get the product implementation.

F

No I'm quite serious right now. We are not showing that we're able to complete work and that that damages the reputation and it makes this work less useful out there. So I think it. That's just not not a very useful argument now on the pub/sub profile. I. Think the confusion is that you actually need a document like like the call cap, the pub/sub document or make use of this profile.

F

But that's not the case. Pops up is just more or less an example application. The way you can do pub/sub, but there are so many other ways in which multiple senders and multiple receivers can work together.

F

That don't all need to be standardized, but they will definitely benefit from a standardized way to do see here at you as multiple senders and multiple receivers, so the pub/sub profile is even useful without any pub/sub document being out there. So maybe this is has been represented a little bit different from from how it actually will be used. I'm, not so sure it's going to be used, and only within the cops'll application.

Q

So that shall be all hats off. Just me, I just categorically disagree with Carson's initial statement. I think um we as Internet engineers need to go and build real things for real applications for real people or computers or companies. However, get some experience out there on how useful is it? Does it take off? Are people interested and we don't have to have an RFC before we do that and doesn't have to be a working group document and I? Think one of the things that's holding us back from getting stuff done?

Q

Is it's just too much clutter here? We've got feature creep in every working group. Around IOT I see like 50 new drafts coming in you know. Three new working group drafts every IETF and none of the core stuff that people really need to deploy. These IOT systems is getting done because there's all this other work going on so stop the feature creep. You know focus on the things that really are getting deployed, get some more experience from those deployments from real customer cases and then come back and say hey.

Q

We implemented this thing because we had a real use case with a real customer and they needed this new feature. No stop my rant. There.

K

From the jabber we have out there saying the idea is that organizations like of OCS will be using referencing group commando squad joining and to be able to use it from OCS perspective. It needs to be an RC, not a draft, not work in progress, so.

H

That's them. This is just another common misconception. We have the same people going on in different organizations and making dependencies and then creating the need for work. As an example, a cousin we've been deploying coop over TCP long before it got finished. It unfortunately took too long, so we actually had then later had problems with different versions, but that's a separate story, so you can do that. But, for example, since the is some of the east toughest, the framework stuff is getting finalized.

H

I would encourage the people in this room to actually talk to their own peers, not just convince people in the room that it would be useful to implement and and deploy it to actually get that real feedback because then like in a way we deploy. We saw some of the the issues that what our customers cared about and I think that's valuable feedback and then, once we go through this iteration, we may need to find you in as a second step, it's sort of like a a circlet.

F

Customer and I agree that there is a little bit of a problem with the deployability of the a stuff and those who were in Yokohama know what went wrong, but we've gone through the process now and we have something that actually might be workable, so yeah I'm not sure that having a product is a prerequisite to writing. A document is a prerequisite to getting an RC we're working on a slightly more complex environment where we have other stos that are looking to the IETF providing building blocks.

F

And yes, not all of these building blocks will be successful so that it's very hard to plan, which one are the ones of those will be successful. But the question on whether arm is interested in implementing it or not. It's not this really. The gating function here.

Q

Yeah, so there's actually um so. Excuse me when I talk about products and what I really mean is implementations, it doesn't have to be a but I'm, not a research implementation customer, not a research implementation. Talking about a deployed implementation that is of product quality, that people can really use on the Internet use as an to do something not uses in to experiment with I think we need to see more of that. It doesn't have to come from companies.

Q

It can come from private individuals that come from nonprofits wherever, but I think we need some real implementation, experience and feedback from people who are using it so evidence that we really need it and that doesn't have anything to do with our more Ericsson or any other company. This is just a way of working that shows hey, there's somebody that needs something they've seen this to be useful. They need some something more for a real reason and that's great and I think we should hold other stos up to this as well.

Q

We've seen tons of feature creep in 4cf in OMA and in many other places, so I think we also should ask other SDS that hey it's great, that you want this. What's your use case, do you have real deployments and implementations? If not, could you go do that and come back to us, so maybe just that bar for implementation should be a little bit higher, and this is not about ace. This is just a more general thing about the whole IOT space at the IETF at the moment,.

I

Turnus anandhan ericsson, so this seems like a very good opportunity to get back to old controversies in a so I will not do that, but that was I was very tempting in this case. In this particular case, the group come it's not a feature creep. This is exactly what is requested. This is the you heard the witness from ocf the chair from fairhair lyons sends me an email and says: what can we do to make you progress this into an RFC I mean? What else can we get here?

I

I mean we have to respect it as Carson says. If it takes two years, maybe they will do something else, but here we have company standing behind. They want to have a standard for this I, don't see the problem.

K

And router from the chopper who, by the way says he's the technical steering committee chair of ocf, and he says. That is why ocf is talking regularly to thing to thing.

I

This doesn't contradict that some companies do advance products of something they believe in. We could have both approaches. I don't see the problem with that either, so it doesn't have to be one way or the other, so that I think it's excellent. That arm is getting doing advance copy above Ace or a co-op or TCP. It's really good.

H

We on a group communication, so we have been working in an alliance, the open eyes, open a EIS alliance, and actually we are in the process of releasing that code that we worked on back then, which was documented in one of our documents, which unfortunately got shut down by by Mike's insurance, because he didn't like the symmetric key version of it, um but will nevertheless release the code. So people can play with it and make use of it.

K

So if we're done with the this discussion, then I have a comment about the or a summary about mqtt profile status from Antony. We've been keeping draft up to date, currently waiting for group to be ready to consider it.

A

Okay, thank you for all of that feedback.

A

Anyone else who wants to speak at the mic. We have a smidgen of time left.

H

Honus again so we are in like rhythm to him: oma we had released version 1.1 not too long ago, uh which is I, think it good achievement and we are going to do in a block first in trop event early next year.

H

So that includes a couple of features from developed in the co-working group, and so, if you guys have interest to participate and there's certain features, also, maybe even if you are not an oilman member doesn't matter because you can come to the black fest, anyone can come to the breakfast or this fest and we are working on the test. Specifications right now, so I encourage you to come and help help us to test test specifications.

H

I can send a mail to the list, borrow all the details. I think that's in I will look it up in April April next year in Amsterdam, Oh, Jen I, actually not I'm, saying.

F

Talking about the black vests, one question that came up in the hallway is that maybe in Prague we could try to have more than two days for for breakfast because it turns out two days. Is you just get up to speed and then you do it the times already up. So maybe we should look at ways to do more, maybe start on Wednesday already or something like that. So we have some continuous time for people to actually make progress.

F

So that's just an idea: that's floating around! You still have a little bit of time. We fall product or make it happen, but if people are interested in a slightly extended form of such an event during so doing ace, do it doing other coop related stuff. That would be a good time. Tour to contact me be honest and me and other people who are interested in it.

A

Okay, thanks for that, oh one, more so.

K

It's my turn to ask the questions to the chair. When do you think we can get the decision on this then after you talk to the ad and like, when can we expect.

A

We're gonna take it. Things to the mailing list is needed. Probably a couple weeks.

K

Okay, thank you. Okay,.

A

So to wrap things up as it relates to the timelines on the documents and milestones relative to the framework document. There will be an update published in December in the DTLS profile again also likely December with the score profile, end of November and then we're gonna do another review in December with the proof of possession- probably very, very soon, maybe tomorrow maybe next week and then for the Coe a best.

A

There's another update, that's going to get pushed out in December, and then we go to working group last call on that draft and that just summarizes where we stand with all the drafts and as as was mentioned before, I started, the the chairs are gonna talk with our ad to work. The adoption and we'll put some things on the mailing list and that'll be a couple weeks. So with that. Thank you. So much for being here, safe travels home to everyone.