Internet Engineering Task Force Interim Meetings, 13 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-STIR-20210913-1900

Description

STIR meeting session at IETF
2021/09/13 1900

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

A

You clicked on the word clip.

B

Must be just that word, I see your slides.

B

Okay, I think russ was volunteering to drive the slide so when he shows up, I will let him do that.

B

Where is the link to the notepad for this session.

A

Are you looking for the button or the url.

B

C

I just had the url and charted it.

D

D

Is this working now man.

B

Yeah, I can hear you what a hater.

E

Let me check too, can you hear me, I think so.

D

I thought that I had already declined to grant these permissions in some previous session and like was not letting me back that out, so I switched another browser now. It's working fine yay.

B

Wait for a moment more see if russ joins.

B

Now I will drive slides until he shows up.

B

Thanks everyone for taking a chunk out of their day to join for an interim meeting of the stir working group. um Our session is, as usual, held under the note. Well, I believe everyone here is already familiar with the note well, but if you're not please take a moment to go, become familiar with it before you contribute to this session in any way.

B

Our agenda today looks as follows: we're currently planning to start with talking about the identity, header errors, handling draft that chris has been working on, followed by a discussion of rcd and then the connected identity for stir updates and the potential charter discussion that comes along with that. Does anybody have any adjustments to the agenda that they want to make.

B

Hi russ, I see that you've joined. Are you fully connected.

F

B

All right, I believe you volunteered earlier to drive slides. I did I'm loading them. I will quit doing this share. You should just be able to click on the the slide share button. That's next to the hand button in the upper left hand bar and they'll all be there ready to go.

F

Oh you already loaded them. Yes,.

A

And I believe, we're still asking for a note taker right all right, someone volunteered that I.

G

A

A

With that jack.

C

A

Thank you very much. You have our undying gratitude.

E

And celebratory music.

F

Okay, so um but let's do the intro, slides and.

B

I think I probably had already stepped through the note well and.

F

B

I did not hear any agenda bashes, but we still don't have well. We have a minute taker jack just volunteered for that. I really don't think we need a jabber scribes group, this small. We can all watch the chat and see um if anything needs to be relayed.

B

Is there any other administrivia? We need to attend to.

B

If nothing, I think that we can move on to the first, which is the error, handling.

B

Presentation and russ at this point, I'm gonna, let you drive I'll, I'm going to um focus on helping with notes. Thank you much.

F

And um chris, this is the slide deck you want. I believe right. Yes, all right, then I'm going to turn off.

E

My video and let you go all right. Thank you. um Yeah. The slides haven't changed from the last time. So next slide.

E

So, um actually, at the last interim meeting, we had a really great discussion about this document and I in fact listened fully again to the meeting again to make sure I captured everything and really put a lot of changes into it, but I think all for the better so uh point one.

E

We moved away from the multi-part mime approach um created text to define the use of multiple reason, headers, something we need to talk a little bit about and then also defined, optional parameter, ppt for reason to hold the passport value directly in the in the reason, header itself. Next slide.

E

um We also talked about uh privacy implications of um the passport. um You know going in the backward direction that it might expose things to beyond the authentication service that sent it. So I integrated specific text to say that it's a must for the authentication service to re, remove the corresponding reason header for the passport it authored.

E

uh When sending the initial invite next.

H

E

um Then I talked a little bit about compact form uh in the document. While we we had a discussion about compact form and putting that explicit explicitly in there to potentially save some bits, and also people felt like that, provided some level of privacy protection as well. So I think that's reasonable. So we put where you could just include the signature similar to compact form of passport and then use that as the key that the authentication service would look at next slide.

E

Yeah, so this was the part that I think you know was the question I probably have back to the group and maybe back. This is also potentially a question back to sip core as well.

E

um Rc 33 3326 um has this statement in it. A set message may contain more more than one reason value, but all of them must have different protocol values. um An implementation is free to ignore reason, values that it doesn't understand. So in order to implement the way that we talked about it last time we sort of have to ignore that rule.

E

um So the way that I created the document is to actually update rc3326.

E

To say that you can have multiple reason, header fields with the same protocol, which in this case would be sip, um I'm looking for feedback on that to see if that people think that would break any implementations or or anything like that, and, like I said I I will reach out to sit core as well after we have this discussion or if we adopt it, as you know, uh as a document, so any thoughts on that anyone wants to provide- or I guess you know, thoughts in general about any of the proposed changes that I made.

D

John looks good to me. I mean just looking at this now and I know we've talked about this before you know I mean, even if it does give people heartburn, I could imagine ways that we could. I mean I don't know how strictly um protocol values are defined, but if we did protocol values, as you know, stir and then like with the dash for different ppt types, even right like as if to suggest that what the actual protocol is, this reason is being given for is not just sip.

D

It's first stir and I need to go back and look at you know if they have any language around what protocol values means there. That would preclude that. But this could let you be like well, you know. This reason is why I rejected you know the shaken passport. This is the reason why I rejected this rcd passport right. If you could like split it up even by um uh ppt types, that right anybody think that's crazy.

E

I don't think it's crazy. I mean I think we could come up with other schemes jack you respond to that.

C

Yes, well, I I don't think the fundament like fundamentally that's broken, but I don't think you could like break it down by ppt type because, theoretically, like you could have multiple passports of the same type. But you could just do like one two, three four, but that does feel a bit silly.

E

That's yeah. I was sort of thinking that actually, um but it is a little bit of a hack, the.

D

Stir might help like you know to just be clear: it's not that we're rejecting some sip level thing, but this is actually a stir level thing and in some cases, having the specificity of which specific passport type you're. Rejecting I could imagine semantically would be useful.

D

I mean you should be able to figure it out from the compact form, but, like you know, I could also imagine you know if, for example, we have these rcd third-party use cases where it's actually like an intermediary that inserted the that one, and so you wouldn't recognize necessarily the compact form as it got back to you. um You know I I I could at least imagine it being semantically useful um to communicate that like this, you know it was a passport of this type that caused it.

D

Imagine if it's like a passport type, that's like unsupported or something like you know. Those kinds of things could conceivably be useful. I don't know it's just just just an idea that occurred to me for the first time. Looking at this slide.

E

Yeah, I think that's a pretty good one actually, and maybe it would be good to just use that.

E

F

So if you were to take john's suggestion, does it need to update rfc 3326.

F

D

No, it defines protocol values if protocol values are, you know pretty strictly constrained in that then it might, but I need to go look. Why not I'll look at that real, quick while we're sitting here.

E

Yeah, that would be my guess if we're defining a new protocol, I think that you know, because.

F

It it's a different process to get to approved right. That's why I raise it.

E

Yeah right one that we don't necessarily want to go through.

B

Let's have a question: um I have not done this um and it would at this point, take me a little while to spin up the tooling to do this, but maybe there are other people on the call that are still actively involved in sip stack work.

B

um Have you tried taking a message that um would have multiple reason, headers and run it through the stack and see if it cared? Has anybody taken one of these things and like showed it through? Whatever the current good packet decoding graphical inspectors are and see if they are upset or not wireshark like things and yeah, it doesn't matter if they do or not other than just having an early indication. If there's going to be lifting that would have to be done afterwards or if it would just sail through right.

E

Yeah, I have not, but it's a good idea to do john. Your comment on it.

D

About that we would that that's some empirical testing needs to be done, but just looking at um 3226 what it actually has is in iana considerations like that, allows you to register those prototype protocol types and so like, and it basically just says that it has to refer to either an it recommendation or an rfc, and so I think, we'd be perfectly within our rights to say we're registering based on rfc, 8224 or 825.

D

You know this and for other ppt types like whatever you know, rfc2b is for rcd, you know, could have its own reference from that. So it looks like it's pretty pluggable if we want to um put in things with finer granularity, whether that would make anything barf whatever it is, is a completely different. Empirical question.

E

Yeah, that sounds like a good path forward anyway,.

E

H

Experience we do see uh multiple reason headers like with like, especially with ship, disconnect reasons more often than not. So, even though it violates the spec you would. You would see, for instance, uh like an superior message and uh two or three different ship uh reason headers in there. So.

E

E

You're saying you've already seen that yes,.

H

E

You so if something.

H

Barf said that it'd probably be seeing that already, so it's not something which is even though it's a violation for their see. It's not unusual.

E

Okay yeah. Thank you, uh jack.

C

um I I guess I just want to clarify the fact that if we had like a fixed set of protocols, if we were going to go down that route, I don't. I still can't see how that would quite work, because, because of the fact you can have like an arbitrary number of identities with the same passport type like there's. No nothing else blocks that. So if we had like a separate protocol registered for each passport type, you would still have the same problem. If someone put two divs, for example,.

E

Well, I think what we're saying is that um we would register stir that would essentially allow you to have multiple um reason: headers, even though that technically violates 3326, but at least it's a new protocol that you know, nobody can say that uh you know like if there's already a sip reason, header and now you're stucking in a new one, at least it's in a separate protocol space, then the other ones, I think, is the logic.

C

Okay, that doesn't quite match what I thought we had said, but that that sounds extensible.

E

Robert did you wanna an okay.

B

Well, it's if we're seeing multiple reason headers in the wild anyhow, um a small document going through zip core that just relaxes the one per the one restriction um should be something that should seal through easily enough. Then we um could still pursue having the um separate identifiers, but um we could just get the the spec part of the multiple header fuel part out of the way yeah and.

A

So you may have just answered my question indirectly. A minute ago uh when you talked about registering stir as the protocol, I was going to ask if, if we can do an iana registration protocol, does that mean we don't have to update 3326?

A

But maybe we still do because of the multiple.

E

Reasons per protocol- I think that's what we sort of temporarily concluded. You know, based on what russ was saying that we wouldn't have. We wouldn't have to update rc 3326. We could define a new protocol and then sort of let the multiple thing go by, but you know, I think robert robert's suggestion is good too. If that's a quick thing to defend, send through sip core.

D

John, you want to go and I think you know the reason why I was barking down the tree of let's register separate ones for separate things is that I thought it would make it more palatable if there were multiplicity of them right and that it just it's likely that if there are multiple passports, they're going to have multiple passport types, did jack's point div. The perfect example of one that violates that, but like that that doesn't mean that there wouldn't be cases where it would disinfigurate it.

D

But I I think, I'm relatively persuaded by jack's point that, like yeah, you need to bite the bullet and say that there can be multiple, um multiple reason headers of the same type present. I'm still not sure that completely obviates the utility of doing separate registrations for separate powerpoint types. But like it's a registry like we can, we can do that and if people want to use it, they can use it and if people think it's useless and implementation, you know all we're costing.

D

Ourselves is a couple of lines in you know on the iana website, so.

E

So was the conclusion there that we should register stir and you can use multiple stir. I just want to make sure I, because I think we had a couple inputs. I just want to see where we settled valuable to.

D

Register sir stir separately from sip just to be clear: it's not a simple failure right um and like if we feel like sub registrations, are going to have a value for some use cases. We can do that, but um I I do think jack's argument that you can. You know maybe 15 divs right. It's really not clear and how much insight is uh you know our relying parties are receiving this and backwards direction really going to have.

D

If there's like you know, divs that they didn't create, you know if they're looking at compact forums, those things got to be peeled off by these entities they go by and like um I'm confident those entities can peel those things off they go by, um but I mean for a case where it's really the um originating ais that is generating, for example, a shaken passport and um an rcd password separately. For whatever reason like that, that's the case we're getting those both back.

D

I can imagine there being some value and being able to differentiate those reasons.

D

It's like I, I I I would say let's for now just like do stir and say um you know it that people who feel like registering more things in the iana registry for um other passport types or whatever can kind of build off of the base star registration and have stir dash rph or whatever.

E

I see yeah and we have time to talk about it as well and think more about it.

E

Okay, um I forget, do I have any more slides.

E

Yeah, so I think that um I assume everybody's okay with the other changes uh like I said, I think we we we had a great conversation about it. Hopefully that brings us closer to something that's more palatable for everyone.

F

So, given the direction we just decided, which is new protocol identifier, instead of a update to the other rfc, my feeling is one more rev. Then then a call for adopt.

E

Okay, that works for me check.

C

Just to clarify, I think it does still require an update to that rfc, because that does very specific, explicitly state that you have to have one reason: header per protocol and even if we register stir we'd, still be doing multiple reason headers for the stir protocol. So I think you still need to update that.

E

Would we want to do that in this document or.

F

Right, I think robert suggested a separate document.

B

um I've almost finished writing the update text.

I

I will paste it into the chat. You've already got the internet draft written.

F

I guess robert's gonna take that one on.

E

Well, that's that's good! We're fishing here.

D

From our problem um to roman's point.

E

Okay, well, and- and I need to well- I could do it either way, but uh I'll I'll send an update uh with that clarification and then I'll also remove the update to 33.25. But uh I can do that quickly. Anyways.

F

Awesome, thank you.

F

Okay. I think the next document we're going to talk about is rich call, data right.

F

E

Okay, uh next slide.

E

So yeah, I got a a number of uh comments from uh from russ and jack and ben um all uh very good comments. uh I think I sent back what I I did for all those um updates in the new document.

E

So thank you to all those review comments. um I one change that we did make at the last minute uh here. Just so everyone everyone is aware, is uh added a new claim value for apn, alternate presentation, number, something that has been sort of been thought about for a while and I think has come back to more relevance. So we thought I mean it's a fairly straightforward one, so hopefully everyone's okay with that one, but uh I thought it'd be. It was important enough to add.

E

E

F

Sorry I thought I had unmuted um when I reviewed the diffs. I uh saw the addition of the apn, but I didn't see um much text about when this would be used. Is this intended for, like the doctor, calling not from his office or.

E

Or something like that, there's a number of use cases and john feel free to add to this as well. You know, there's toll-free use case, there's other scenarios where the presentation number is different from the calling number um john. You want to add to that.

D

Are people asking for this man? I I got worn down on this because, like the the party line, I was trying to tell on this. So we when we did our cd. We made this like one off for nam right. That is like separate from what you do in a j cart that can contain the display name that is shown in the from ever field and, like you know, the the story for alternate presentation number that I was trying to tell anyway was well. You do a very simple j card.

D

You put a tell uh field in the j card and you have the telephone number in it and you're done, um but I mean I think I've been gradually worn down to the point that this is a common enough use case enough. People are clamoring for it that this is worth having a one-off like now. That's really what this says. This is just saying: there's going to be one more thing: that's like them! um You know I. I would rather do this than you know to describe one presentation.

D

One proposal that I heard recently then put the display number. The intended presentation. Number in the display name field of the from so that it would show up, and now when I saw that it had something that was being floated. I was like: okay, let's just do another one-off. That makes it clear.

D

This is what the alternate presentation number is rather than people like overloading nem for it, because they don't feel like having to do a j card when all they want to do is put in a number um so that that's what sold me on this but jack, explain to me why I'm wrong we're right.

C

I wasn't actually, I was just going to ask why. Why then is apn kind of it's it's jay card or is jcd jcl, but nam can be included with a j card like. Why are those different.

D

The must not for if you're, using apn, you must not have a tell on the j card yeah yeah yeah. I mean that that was just to make it clear that if you're already doing a j card for some other reason like you should just have to do apn, if you believe we should apply the same to nam, um I guess in principle. I wouldn't object like that.

D

If, if you're having a g card at all, let's not have any of the shortcuts, like all that stuff should appear in the j card, rather than being fields that you have to parse separately because yeah like what, if there's a conflict or like I mean I just want to get into that, I hadn't thought about. You know that really the same arguments making for apn applies to nam. I I would be okay, if that's the restriction, you're suggesting.

C

I'm not sure I have opinion. I was just confused by the difference.

D

C

Want there to be conflicts.

D

J

With the name, what would the equivalent be in a j-card, we kind of been looking at it, and I mean for an individual, it's the first and last name, maybe, but for a company, it's the organization, you may not have a first and last name.

J

Concern with that is name kind of provides the ambiguous, if, if you can only display a limited set, here's what I want.

E

F

First, if he's going to respond to the last speaker to jackman.

D

I totally agree, I mean, I wonder: if there couldn't be, you know I mean, is there any similar ambiguity, even with tell I was just trying to think? If there is, I mean I know you can have multiple tells and they can have you arise and stuff. They can be like fancy in a j card, um and so it might actually be ambiguous, like which one you intend to be the presentation number if you're doing it intel.

D

um I mean there probably are some ambiguities that surround all this, and I I don't want to undersell that. But I your your point- is taking alec that, like that, that does make this semantically different, because people use the display name in the front header field to contain a variety of information that could be personal names could be organizational and you know do we want to say if there's a noun present, you can't you know you can't have organization in jay card right like that.

D

It would be a different set of prohibitions that we need to construct around that if we intended to prevent literally any conflict with that.

E

There's sorry, I was going to say, there's the functional or sorry for formatted text, fn property, which seems to be the one that is sort of the equivalent of name.

E

um But we haven't defined that as you know, that way, but it seems like that's the one, at least in the examples that is closest to what just the general one line name value is.

J

Yeah, so I mean like today, we'll put our cd information in a shaken passport and it could contain a j card with a first name, a last name and an organization name, and when we, when we verify a call we'll we'll take out the name, claim and set that as the pai header, if there was a first name, a last name in an organization, what would we set? You know that may exceed character lengths, the combination.

J

How would you merge them into one you know displaying because we're trying to make it work for a dumb handset? It could be a pots line right. It's just you know, setting the cnam so that it it's not much, but at least it's a little bit of rcd information. That's sent to it, so the name provides a nice ambiguous. If all I can do is a you know, pretty plain text, I'm just going to use this yeah. I think now that I think about it.

J

The same thing could happen with the tell uri right, because you could have a work phone, a mobile phone, a home phone right in the j card, and it would be unclear which one you were using for the alternate display or alternate presentation number. But if you have a specific field for apn, then like this is what you use. It's very clearly telling you.

E

Yeah, I tend to agree- and I think you know you saying that is- is sort of how I think we thought about it originally as well. It was sort of like the default and we required it so uh so so I think maybe that's sort of the differentiation.

E

Apn is a little bit of a special case, also sort of a default thing. If you're not going to use anything else, but I think there's more correlation to some of the fields in jcard. If you want to use it in jcart as well russ, you want to go.

F

So is the passport signer expected to do anything to validate the apm.

F

We expect them like in the shaken model. We expect them to be authoritative about the the uh calling number. What about this number.

D

I think I think we are expecting some level of valuation to occur around that and, like um I don't know if we want to put specific policy of what people are supposed to do to do that.

D

But you know jack can probably speak to the uk case better than I can to the distinction between the five types of presentation numbers and, like the network number and so on, and the ways that those things are allocated in uk but like yeah, and I I mean I think I am increasingly persuaded, because this is one of the issues that came up with tell as well like if you were going to use. Tell for this, are we sure the semantics of town are?

D

Actually it's the presentation number right and you know the reason that this comes up. Is you know, precisely because there could be alternate versions of different numbers that are intel and which one is actually intended to be? The presentation number is the question. I tried to tell the line that like well by having j card b and rcd at all. The entire semantics is.

D

This is intended for presentation to the end user right and it's kind of up to the ui, how it's going to parse those and sort those, but it's going to do so with the understanding of whatever it is. That's in our cd. The intention is end.

D

Users are going to see it and like, but but this conversation convincing me, I think that that that that may not be tractable and then that ultimately might be worth having an apn, even in those cases where there is a j card with a tell in it precisely because it indicates this is the one that we intend to be present. You know the presentation number, in which case we should remove the restriction. That's in it now.

J

You know when we were kind of looking at maybe more like legacy network. um I mean not no ancient necessarily, but not things that support really rich call data. A potential you know use case would basically be the verification is like creating a pai header with this apn number so that it shows up when it's sent to the handset right that that's kind of the intent that we could use. So the name goes in the display name of the pai and the apn goes in the number of the pai.

J

So when it's sent to the handset it dumb handset that just does basic cnam and basic number display. But now you get the information. Is that correct.

E

Yes, okay, yeah. I think yeah.

J

We say from or paid.

E

Or uh what was the other one alternate? Something alternate number. I think.

E

E

C

I got distracted by trying to type what's being said, um the yeah, so I think I think the the thing there is like name and.

C

Presentation number are kind of different because there are standard like there are standard ways of presenting those to the user already and so like having a nice way of keeping them separate and unique and like easily like. So you don't have like have to do some lunging with the j-card to work out. What on earth you want to display um would would would definitely go towards the fact that we should just remove the requirement that if you have an apn, you can't have tell in the j card to be more similar to nam.

E

Yeah I I sort of buy that holla.

K

That it's going to be presented as the tn as the calling tm so that the called party doesn't really realize this is an alternate presentation number it's just the number that if they wanted to call back is that it, but we are calling it alternate presentation number, because we know it's, not the real number they're calling from correct. Or am I missing something.

D

Correct it's that we know. We know it's not the network and so yeah, because of that it will. um It should be the thing that shows up to the user, but for cases where there is a separate network number you know, uh operators can still leverage that for their own sinister purposes. That's the idea. Yeah.

K

So at what point is it at the originating end that um we are submitting all of the certificates, delegate, certificates, etc, just proofs of um uh authorization that this party is still entitled to use? The alternate presentation number it's it's at that point, just like all of the good passport stuff that we have created so far.

E

D

I think the interaction with jwt constraints is identical, so if it all gets hurt or something you could still have constraints around it.

K

E

But it thinks it is part of the rcd, so I think the intent is that you know this is sort of extra information.

K

Okay, so there's no extra um verification being done just because it's an alternate.

E

H

E

It should be, uh there should be more scrutiny of rct or well, I don't know, maybe equivalent scrutiny, um so I think it should be validated just like any of the other rcd information.

K

Okay, thank you.

E

E

All right, good discussion, um I think I included uh we sort of already talked about this. I guess, but I included the example so.

G

So I have a question on who determines that? To put this apn.

E

It probably depends on this yeah go ahead. John.

D

Whoever is creating the block of json that you see in front of you now and choosing to sign it right, and so I mean in in a shaken like regime. It's the you know, osp right area that is generating this and sticking it yeah, and so I mean it's if osp is going to vouch for alternate presentation numbers that they shouldn't. um Of course that can be an issue right in the same way if they vouch for ridges that they shouldn't that can be an issue.

D

I'm just not sure I saw a material distinction um in the permissions model around that.

E

Yeah I mean it's, it's it's mostly about callback number. I I believe so it's probably a decision made um at the enterprise level, but who, whoever vets, that or authorizes it through a certificate or or whatever the mechanism is, I think, that's dependent on the use case.

G

I see okay, so is there any use case that the end user can choose to indicate.

E

Say that again, is there any what that they can indicate.

G

End user say, for example, uh you know: can I indicate to you osp that every time I call I would prefer to put that vpn instead of the you know, real number.

E

Yeah, it all depends on the authority model right like um if they're, if they have the right to use that number as a presentation number, they probably have to get that embedded and a certificate created. That would include that in you know most cases but, like I said we have a couple different models here, but you know, and at least in the one we're intending to use and the the quote unquote shaken model. uh I think you would have to get vetted and applied.

G

Okay to the authority, okay,.

E

Yeah, it wouldn't be just a editable field or something like that or you just program it into your phone or something like that. Nice, okay,.

G

F

Yep, uh I think I do think we'll need some kind of of text in the security considerations to say you know, don't sign it. If you don't, you know, have confidence in it belonging to the so that something about the correspondence right, uh yeah.

K

Right and- and that goes back to my question chris- you know a few minutes earlier- that it should be clarified uh who is actually vetting the authorization to use this alternate number making sure it is not um something that the end user can program in their phone, like you said so some text to clarify that and that it should follow the same um regis, whether it's a registration process. You know like the registered caller solution, etc to that effect just to clarify so people don't get nervous.

E

Yeah yeah thanks, but which.

K

J

K

E

The rest of our cd information that we want to include here, but um yes, I I agree, we should make sure all those precautions are given and clear.

E

C

E

uh I'm not sure I specifically recall uh you know, I think.

D

E

We missed the beginning of what you said. Sorry.

D

Oh, as I was saying I I was in q so long ago. I I know I'm not sure I entirely remember what I was gonna say. Oh.

J

D

Think I was gonna say yes, that this is like. You know additional identity, and things like that and 3gbp plug into you know, like p, preferred identity and things like that right, so they're, it's not that there aren't um mechanisms that, like enterprises or things like that, couldn't use to suggest. I want to use this alternate presentation number for this call, and so I I guess we're not gonna stipulate like what the way is that happens here, but there are a number of at least somewhat standard ways to do that.

E

Yeah, maybe we could enumerate a few of those.

E

Okay, good next page.

E

Yeah, so there's um uh we're having a little bit of a list discussion on um and- and we can actually talk about that here if we want to um but uh like I said before, I I submitted a whole bunch of fixes. I think we have a few.

E

Things out of this meeting that we talked about fixing as well, but yeah, I tried to maybe give a summary of the bigger things. uh One was consistency of logic um with the rules around constraints. um So let's pause on that, because maybe we want to discuss that um the uri recursion rules- I will- I haven't- had a chance to like really deeply read through that, but um I I took all the points from how it was confusing and there was a few logic errors there.

E

So I'll make sure that's consistent, and hopefully everybody understands the intent at least and yes, jack brought up updating the hashes. So I did go through the work to create those um but ben. You want to comment.

A

The discussion on constraints and I've seen verification rules isn't the right time for that or another slide nope. This is the last slide, so it's the time. Are you done with the others? If anyone wants to talk about the other, then I can go back and wait now. Let's start talking about constraints, okay and I'm glad to see. Alec is right behind me in queue because I was gonna, maybe call on him. uh The.

A

I assume people have seen some people have seen the emails, but they were right before this meeting, so maybe not um right. Now the clarified rules on verification and I'm not necessarily disagreeing with them. I'm kind of just poking at edge cases says that.

A

That the verifier has to verify everything. We've got these. You know interlocking now, mechanisms between the signature itself, the jwt claim constraints and the rcdi, and the use case that I think I've seen some people over on the ip and I side of the world. Thinking about and and maybe alec can can pop in a minute and tell me if I'm on base or off base is a use case where a caller has a authentication service that is signing with a delegate certificate and signs an rcd passport, and that passport has two purposes.

A

One of them is to uh basically authenticate itself with a originating service provider, and then the other one is to put push rcd claims all the way to the call endpoint or at least somewhere downstream of the of the osb.

A

So that could be a tsp or it could be the handset, um and in that particular use case, the osp really just cares that the signature is good and that the number is in the tnl's list and my concern, if we put them in a position where they're having to verify the rcdi, including likely downloading a logo or icon, to verify that, because I mean the whole reason rcdi is in there probably is because you've got external values in the in your rcd.

A

um If that puts an undue burden on the osp and of course I.

A

Chris came back and pointed out rightfully that any idea that you validate some things that don't validate any other things can can, you know lead to madness and maybe there's other ways that people should be thinking about doing this and and I'm okay. If that's the answer, I'm just kind of trying to poke and be an irritant here.

E

I I don't know, do you want to talk first alec or do you want me to respond or.

J

Either way, I I I think, I'm on the same page as ben. I I think, but I would actually take it even a step further. You know I I guess I would say I view rcdi verification as something that really should be done by the the end device. That's about to display it. If it fails, then everything else is fine, because you know the kind of use case. You know we, like you know you.

J

Let's say you want to include three different logos: one for an ios device, one for an android they're different sizes, so the osp in ben's example doesn't verify. They don't go fetch the resources. They'll verify that the rcdi claim matches the claim in the delegate cert, but they're not going to do any resource fetching and then, when it gets to the tsp, the tsp does the exact same thing.

J

The tsp sends the url, as well as the integrity value for that url to the device and the device when you go fetch something you're responsible for checking the integrity. So I don't think it creates too much madness. As far as verification, you know, you're, not verifying everything, you're verifying everything but rcdi, and only the resources that need to be displayed are fetched.

J

If you take that approach, that does mean you have to pass the rcdi to the end device whatever is going to display it, but it saves you all these resources, I mean you could have five urls and if you're only going to use one or maybe even none having to go fetch them, and it also gets to a point of what, if the server that's hosting, that logo is down, if your passports fail verification because the load the server's down- well, I mean it doesn't need to.

J

You could just not display logo, but you get the ad station elevation. You get all the things that are embedded in there. You just can't get a logo, so I think I don't think it creates too much madness to push that responsibility of verifying integrity down to the end device. That's about to display that whatever that is, it's gonna check the integrity of.

E

Yeah, I think the way that- and you know people can push back on me if they want to, but I think the way that I like to think about this is shaken and this middle of the stream verification that osps does is a specifically shaken thing.

E

um I tend to like to think of the itf specs of sort of the pure implementation, and we talk about what happens at the authentication service and what happens at the verification service.

E

I don't know what the thing that the osp does is that a full verification service is that something else, but I think it would be a shame to sort of pollute the speck to try to accommodate that use case. And then you know, like you know to me it doesn't seem clean and it.

D

E

Seem uh like it'll, be helpful to what we want to do in this specification.

E

If we want to make something that talks about that more specifically, somewhere else or in a different ietf, spec or or somewhere else, I think that's what I prefer to do, but um um I don't know I like to hear people's feedback on that.

E

I don't know if that's what you wanted to talk about jack or does if anyone else wants to respond to that.

B

Yeah, throw in real quickly that I resonated very strongly with the um path that you just described chris, I would be. um I would work hard to keep that division of description in place.

E

B

E

Go ahead, jack.

C

Yeah I I kind of just wanted to repeat what alex said and essentially, as soon as we read the spec, we were like well, the verification service can't do this, because it's just gonna take too long and so we're immediately like well we're gonna have to work out how to push this onto the end devices and the whole like verify that everything looks correct, but don't verify the rcdi digests and just pass those on to the end devices is the obvious way of implementing it.

C

um But I don't think I disagree that um the spec doesn't have to be explicit about that, because just giving up the verification service between the service provider and the end user isn't far-fetched and seems like a reasonable division. But I'm I kind of just wanted to say that it's it's not going to be a edge use case. It's all. I have a feeling it's going to be the only way it's implemented unless someone implements a verification service, but purely on the end user device.

E

Well, I still think the end device should or something close to the end device should be verifying it again, but um uh why don't we let I don't know I I think john's next.

D

You resonate with the strategy about, let's do in the itf. What does the itf give us caesar? What is caesar's and leave other things for other places? I I definitely am on board with that. I put some notes in the chat about this.

D

I mean you know I I guess if you know, if we're talking about just validating the passport itself, not traversing any links or whatever, like you know, if there's a situation where we want the base, say shaken passport to succeed and if rcd doesn't validate, for you know that not to fail- and this is one of the use cases.

D

I guess I've heard people discussing that they're concerned about about this, like the solution that to me seems pretty simple: if you don't want them to share faith, put them in separate passports, right have an rcd password, that's like separate from the shaken passport, then the rcd passport can fail on its own, but I mean I can certainly see a strategy where you're just like look, if there's a passport with a mix of like shaken stuff and rcd stuff in it- and I just want to validate that that works and, like you know, not traverse any of the links lower down.

D

But just does. Does the json signature over that password like validate um and use that as a basis for accepting origin dest? I I wouldn't see any prohibition on that and I rather like the idea of having like the rcdi stuff, only fire off when it literally gets the end device. That's that's, I think the end state we all want for this is, for you know those those links to actually be things that the end devices that are rendering to users would be able to access directly.

D

I'm not sure, I'm optimistic that we're going to get to that in-state anytime soon. I think a lot of operators are going to want to do this and then you know, I'm sure there are 15 more verstat, like you know, editions that will be added to the asserted identity for all the links that you know are now pointing to the tsps network and its cache of those values. Instead, you know, but that caveat aside, that we'll see shenanigans like that, you know I mean I.

D

I think it certainly is reasonable to say that you're not going to fail the passport, um because you ignored like the those links and you just don't care about. What's what's in the cert, for what the permitted values are for those things, um so I can live with that. If that's is that commensurate with what you're saying, alec and jack.

J

um Yeah I mean for me: it's it's yeah, I'm not saying we necessarily need to mention shaken or anything like that. It's it's just generically! I, I guess the integrity, I think, should be verified by the device. That's about to con display that url um that resource that was whatever you know, received from the url, because in any situation you know you have a verification service, that's doing more complex. You know, verification of the passport and the certificate, the cryptography all that stuff um and then passing a bunch of urls down to the end device.

J

The url is going to get selected by the end device.

J

The the entity doing the verification may not know what the end device is going to do, and so, if you're, putting that responsibility verifying the integrity on that, then it has to verify all of them versus if it's the end device that does the integrity verification, then it knows what it's about to display. Maybe maybe you have two urls for two different images. One of them is a high res, and one of them is a low res and you try and get the high res and it doesn't work.

J

It's not even integrity fails, but you just get a you know: 404 error or server timeout, and then you try the low res and display it. I mean there could be some logic in the end device and I think, having that device, do the integrity, verification just pushing all integrity requirements down to that end stream device makes makes it clean, and it is a good separation of responsibilities.

E

I I generally don't disagree with the conversation here. I'll just ask one question: do we think it would be a bad thing if the osp verified the integrity and the images.

C

I don't think they will. It will just take too long.

E

I agree with that, but just maybe from a philosophical point of view, do.

D

You mean osp or tsp chris osp.

E

Well, yeah, I think I hope we all agree that the the tsp or the end device should always validate the integrity. um But what I'm saying is you know like? Would it be a bad thing for an osp to follow the rules that we've set, even though we don't think that they might?

E

I don't know- maybe that's just a exercise than that anyway,.

A

I don't think it is a bad thing. I'm I'm mixing cues, I'm going to jump in anyway. uh The I think there's another use case which requires that and that's the use case where an osb validates the uh um rcd passport and then turn around and writes those claims into his shaken passport before sending it downstream, which that means he's vouching for it, which means now he owns it right. So he better have verified the integrity, see.

J

I guess that's. I don't know that. I agree with that.

J

Why I mean the osp.

J

Why do they need to to dereference the url make sure they match the integrity? um If, if the osp gets a delegate cert- and it says you know- here's the rcd information that should be in there- here's the integrity, values that you should get when you dereference it and they verify the delegate cert and that's all fine. They put it into the the shaken passport. In this you know specific to shaken example, um and the image doesn't verify to the integrity that doesn't really change anything um because the end device won't display the image.

J

So I I think that's that's a critical advantage of not requiring the osp to do it or not, requiring the tsp and just pushing it all the end device as an osp software vendor.

J

That could be very slow and I think that will decrease the likelihood of people using that. So it'd be great. If we didn't put the osps responsible for ensuring rcd, I is matches the resource so.

A

I may have overstated that. I was meaning to argue in favor of it's okay for them to do it, and maybe I argued for they must do it, and I didn't really quite mean that. um But I wanted to address a couple of other things that we've kind of back in the queue uh when we talk about render and decision.

A

My concern is the current text says you can't render diseases, because we've got text in there that precludes not fake sharing. All this, or at least in the the proposed text um and there's ways we can write this- that don't require any knowledge of shaken or or or any particular.

G

A

A

Before you can just say that uh a relying party must not rely on a integrity, protected rtd claim without verifying integrity.

A

um And you know, I would argue that the relying party on that rcd is the party who's going to use the rcd, not the osb. In this case- and you know we all know, there's as much as we like the end device to be the one that renders all this and does the verification. We know good and well, there's going to be tsps they're going that are going to eat that rcd passport and just show the uh claims into their uh um separator fields. Kind of, like you, know, kind of easy name style.

A

We know that's going to happen, but we.

E

A

Text, it doesn't say it's the end point. We can just write text that says relying bertie.

E

And that that, to me provide is why we should sort of stake our ground, that, if the usb is going to do that, they they better check the integrity. Right, like uh um I mean I still well.

A

Anyway, right: well, that's my point is I I meant tsp, but my point is the relying party the party that is going to either use that racd claim data or they're going to assert that it's true to someone else has to has to verify the integrity hashes. If it's there.

J

I don't know I I mean how how is the t gonna send to the end device the image.

A

J

A

They can send it in a call info.

J

Yeah but they're not going to send the image they're going to send the url. So I don't know, like I said earlier: they'll make their.

D

Own copy of it right, I mean again, like I agree with ben these guys. These tsps are going to munch this six ways from sunday, because you know why they're gonna do it they're gonna, do it for like data privacy reasons, because they don't want the the endpoints to be hitting the origin servers.

A

But I think we're we're poking at the wrong layer here, at least from a standards perspective, I'm not suggesting that we need to say or even know anything about how these things get consumed, but we need to say is: if you're going to consume them, you better verify it if you're not going to consume them. It's not your problem.

D

This is the rub, and it really comes down to what we mean by consume and, like you know, a case where an osp, for example, gets a delegate passport from the enterprise and is just doing enterprise at a station, pulls that rcd out and sticks into a passport they're now vouching, for I would be surprised if they feel like they don't need to validate that right, because now they're the ones that are signing for it and vouching. For I think it's a different.

D

I mean again, if we, you know, think about. Like liability, like I think it's like a different landscape when that passport that came from the enterprise is merely carried. In addition to this is like the fake sharing point carried in addition to a shaken passport that is added by the osp, the case where the osp actually compiles them.

D

I think the usp effectively can be interpreted as vouching for them, and these are the kinds of like political things that are gonna really change to calculate this, which is why I like the relying party being defined in a way that any originating terminating or even like endpoint. If we ever get to that nirvana, where, like endpoints the ones that actually see these passports, is the relying party it's their obligation where they are to do this right, that's that's what I was trying.

E

To try, I don't know if you're agreeing with me or disagree with me, I think the agreement I'm in agreement makes it clear why we need it this way right exactly like. I think we already have what we want.

E

I mean, maybe there's some more clarifying language we can put around it, but I think if we try to clarify it too much we're going to create confusion, but maybe relying parties or some something that represents that and rather than trying to enumerate tsps and osps and and devices, and all that other stuff is the better approach.

A

But to clarify one thing: we're doing there and- and I can also accept what john said earlier. That said, if you don't want to share your passport information to put them in separate passports, uh but the what we're saying is that a passport can have more than one relying party and they can have partially relying parties. You know they're relying on part of the passport, but not another passport, and I think that's okay, but I you know the security guys might get high enough with it. I'm not sure.

E

Yeah, I think that was sort of the point. I was trying to make that, rather than trying to do half measures, um we leave that either for another day or for people to do beyond the specifications or something like that. I personally I discourage it, but maybe that's just my personal point of view.

C

I think an interesting thing here is that the especially in the case of like the osp copying the rcd information into like their shaken passport, which for separate reasons that we're going to into is a, I think, a bit silly use case. But anyway, the the osp, a failed verification, isn't an indictment on the osps like um reliability or whatever, like that like how much you should trust them.

C

If the passport fails, you don't really it's not really saying anything about like whether or not the you should trust the person who created that passport, more or less, and so there's this like weird thing here by copying the rcdi across. If that rcd information is gets, changed or something like that, the rcdi will still verify and it will cause the passport to fail verification.

C

But, like you, the osp hasn't vouched for the contents of the rcd. They have vouched for the fact for the contents hashed by the rcdi.

C

So as long as they're happy with the rcdi contents like they've pre-verified it or something they're, not really, they don't need to go and check that the rcd, the things referenced in the rcd actually matches. What's in the rcdi, because, like the whole point of this scheme is so that you can change what's at the rcd and it will just cause the passport to fail, validation or like the logo, will fail, validation or whatever.

C

So in some ways, the osp doesn't need to check that the rcd matches the rcdi, because as long as they trust as long as they've validated the rcdi information, the digest themselves so they've, pre-agreed them or whatever, then then, it's all fine right, because they're signing the rcdi they're, not signing whatever's hosted at that url.

E

I don't think we disagree, yes, but it's um you know whether we want to explicitly document a mode that talks about that or not, I think, is more of the debate.

J

uh Yeah, I I I completely, I I I see the distinction. I am wondering so I mean it. I guess to me it would. It doesn't make sense to have multiple people verifying the integrity right in the chain like why? That's really, I guess the way I'm viewing it. It doesn't make sense to have you know three different people verify that the contents of that server match the integrity.

J

You only needed to do it once um and I guess the only thing I I I kind of view integrity failing as not a passport failing and in a way kind of a good way of putting an example is what, if it's not integrity, fails just the server times out it doesn't respond it it takes too long. It's down.

J

You know. I don't know that. That means the passport failed. It really just means that one thing that you're trying to get is not available. It's I kind of treat integrity. The same in in shaken um in addis 1074.

J

We wrote some language for the for the case of the verstapp parameter, where we said you can only send tn validation past. If you send the attestation downstream or it's at the station, a right like that was the way we got around that kind of issue I feel like. Maybe we could do the same thing here.

J

You you. If you get rid of integrity, if you don't send the integrity downstream, you need to verify it. If you send it downstream, then it's the downstream person's problem. So if the tsp chooses to dereference the url and host it in their own web server, they need to verify integrity clearly because they're getting rid of the end integrity going to the end device. But if you choose not to do that, you pass integrity downstream. Then it's not your responsibility.

J

um Maybe that's the way. We approach this. If just saying you have to verify it as soon as you get rid of it.

E

D

Yeah um I mean I. What I don't want to do is place constraints on who we expect relying parties to be in the architecture that could potentially be limiting downstream right, like in terms of ways people want to use this I'd rather have a universal rule that you know works respectively. You know it's like an intermediary or something that, for whatever reason is like mung rcd, and this doesn't even get into third-party rc cases by the way, which are a whole other.

D

Like dimension of the story, um but yeah I mean, I guess my point is I. I still think there could be cases where the osp- and I put some in the chat like might be interested in making sure that the links are validating properly, because once they're signing them in a passport they're taking some responsibility for those things, even if they're not going to validate downstream right. Like I mean it's, that kind of just policy level stuff that makes me think we may end up.

D

Unfortunately- and I agree it's it's- the end state we want is one where nobody cares until we get to the device it's actually going to render this that's the end state we all want for our cda. Nobody needs to validate it under that other than that device. I just fear there are a whole bunch of cases where other people are going to want to validate it. There will it'll be redundant validations. It's it's a waste of time, for all the reasons, all the technical reasons, but for policy reasons, it's not a waste of time.

A

So I think that the uh I mean we can cut through all this by just defining that the relying party for the rcdi hash is whoever needs it.

A

uh I mean if I can see from what alec was saying if you have an osp that that copies the claims to their shaken passport, but they also copied the rcdi and send it downstream. Then they weren't really the relying party for rcdi it's whoever further downstream, does it. uh If, on the other hand, they feel the need for some reason or another, some policy or something to do it, that's fine, they can do it too.

A

It doesn't hurt anything uh whether it's a good idea is not our problem, so I, but I think, what we're the conclusion I think we're coming to is that the rcdi has its own, relying party which may or may not be the same, relying party as the rest of the certificate as the signature and the and the jwc claim constraints.

E

I think when we talk integrity, we think a lot mostly about images, but I wonder what, if it's a jcl, does that change anything.

J

It makes the problem even more important that we don't require to verify it in the sense that it could require two round trips. You could have to go hit the j card and then go get the url sequentially, um and so that's why I really hesitant about the expectation that the osp or the tsp do it. If they're passing the integrity downstream um gets even worse. When you talk about kind of having both.

B

So I think that I would like to call attention back to what our chain of trust is and where trust is rooted in what these attestations even mean and a lot of the.

B

What's being claimed in in a passport is based on trust that there is a relationship between the the um signer and the entity that the signing is taking place for right, that the signer knows and has proved that that entity is the correct person to make the claims that are in that passport when there are claims that contain uris.

B

The trust model to those uris are very different. The what we've engineered is the ability to verify that the person that we are signing for has handed us a integrity check that the integrity check, checks out and that's it um when we skip that integrity check um the the we. We just need to be very clear that all we're talking about is that the.

B

Trust back to the the the end user was entirely in what that integrity check was made. There's a whole suite of potential attacks that we should, at some point, perhaps investigate for what happens when the web server, that is maybe not entirely under either the the signing parties or the end users. Control um decides to serve a completely different thing and we've got a pretty good.

B

um I think we've done a pretty good job of capturing in the the documentation that all we've done is is say that the the attestation is is that, at the time the signature was made, the stuff that was in there had the bits, if nobody's checking that we need to be very clear that.

B

I'm about to say that the checking hasn't happened, but I really don't want to step in that um specifically just yet. We want to be very clear what the um trust model around the the veracity of of that eventual source data is, I apologize for the ramble, but I I think that keeping those separate is going to be helpful.

E

Yeah- and I think I I totally that's exactly where I started from- I think- maybe there's room for like if we use the words relying party, um we can sort of change it around so that um you know. I agree with the premise that you know if you're not going to display an image or or something like that, then that- and that has nothing to do with like the telephone number.

E

um Maybe there's some room for that, so maybe we can sort of craft it in a way that we're not making the logic complex, but we're maintaining the security around and the integrity for those that need to use the integrity. But uh I forgot it was next russ for you next well.

F

I'm going to respond to robert in part, so I should probably go next.

F

The we we put the hash of the thing you're fetching um into the the claim to make sure that, even if it was a web server that you're, not the administrator for and that administrator swapped the image that would fail because the hash wouldn't match.

F

So we tried to eliminate one aspect of what robert was talking about, but whether the image is appropriate or not still falls to a policy question.

E

Right that said, the signet, that's at the creation of the image and the integrity right, the the end user has to at.

F

E

Time the passport signed is where that menu is. When you verify it, you sort of trust that that has been done, and you put in the trust and the signer of the information.

J

I think we have to be very careful with the integrity.

J

You know not to say that the osp isn't allowed to, but it's kind of meaningless if the osp verifies it uh or the tsp for that matter, if they're not changing the url, if you know I get a let's say: I'm acting as an osp and I get a delegate cert and it's got an you know, a link in it, whether it's an image or a j card, and I go fetch it and it matches the integrity and then I send it downstream and then downstream goes and fetches it. It may not match anymore.

J

An attacker could change the contents. The first request I'll return. You know the data that I'm supposed to the next request. I won't, um and so I think really integrity is only valuable if you do it and then use the url or use the contents. If you are then passing the url, it's really it's kind of meaningless.

J

um You kind of have to do it at that last point: it's not saying. Osp can't check it, but just because osp did doesn't help you downstream. You still have to check it.

E

Yeah, I think meaningless, is a little strong. Although I understand your point, I mean like, if somebody's actively just sending um unverified images um because they were given an integrity value for a different image than they're actually sending.

E

There could be some value in the osp doing it, but I I'm not advocating that. That's like the only thing we need to do like. Ultimately, hopefully that gets catch caught at the at the point where it's actually going to be displayed or or or sent to a handset or wherever we're talking about.

J

I I mean, like maybe meaningless, was too strong, but I guess kind of getting back to the liability. It's I guess it's. Maybe it's kind of important to recognize that the osp is not liable it because they kind of I mean unless you're expecting them to dereference the url and then create a new one. That can happen.

J

So I think you kind of have to be careful and not you know the the osp. You know. Let's say we get as an osp. We get a uh some image. We we verify it. We say: okay, you know we like this image. It's not some inappropriate image, it's reasonable! We check, we have its integrity. When we get that that claim you know, here's the the url and here's the integrity. We we. We are okay with this integrity, it could change.

J

So I think we kind of just really the osp is responsible for the integrity they're, not responsible for the contents of the server. I think, if you look at it that way that solves the problem in a way that.

E

But I think this goes back to maybe the original point of, like maybe that's a best practice that you know we determine you know we're saying today it doesn't matter if the osp does it, but maybe like, for whatever reason, it'd be better if the osp solved that, because we're getting a lot of people sending false images or something I don't know, I'm just making something up but but but I think the point is that, like from a protocol spec point of view, those are more best practices.

E

I don't know if that's the right word, but you know that those types of things that I think are appropriate for ipni, specs and- and you know more usage specs rather than the core protocol, where I think we just can focus on the authentication, service and verification service. And then you know where those things are performed and what level they're performed, um but it.

E

But I I think where I'm agreeing is like, maybe we can have some relying party words in the verification service that stretches it a little more to allow you know so that it from a spec point of view. It's it's okay, but we still have. You know the strictness to say that you should really be checking the integrity or- or I don't know something like that.

A

We've talked quite a bit about this, and I think we we're in danger now start talking about what people should do in best practices and we'd be best off. We just maybe get some text about what we think we agree on and then see.

C

A

We closed the queue for this point after a jack who was already in queue. I only raised my hand, so I make a marker in the queue.

C

Okay, yeah, I feel, like I've, been on the queue for quite a while now um the so.

C

I think I would possibly go further than what's been said so far and that the rcdi, failing that the digest failing to match is, should not be considered a fail like a verification failure, because there are situations, for example div, where the person who's diverting it. The server could have gone down while they're diverting it and come back up afterwards them failing the call.

C

Well they well sorry, not them failing call, but then failing that verification and throwing some error is a bad thing to happen. At that point, and even just in a like straight line case, the tsp verifying it if they're not going to like re-host the images or something like that, then they they can't reasonably.

C

If they, if they validate the digest, they are doing it like they're doing more harm than good, because for it like there are so many situations where, like maybe one of the logos, has gone down, but the other one's still working like if they verify that they have prevented some rich call data reaching the end user, where everything that the end user wanted was fine.

C

C

I would go so far as to say that the like the digests not matching what is at the urls should not be considered verification failure and only the person that is extracting the information out of that uri should be doing anything with that digest and even, if that fails, all they have to do is just discard that single logo, or that single, like whatever it is. They can just discard that and everything is still fine. They can even carry on with like the nam, because the nam the nam has been signed for.

E

I don't know the the case where there's like an operational issue like that the server's down- um I don't know if it's good to define the protocol based on those things I mean. Maybe it's worthy of consideration, but um I don't know if that was your only point jack, but.

E

I tend to think you know you know like those are. If, if a server is down, then unfortunately, things will fail. um Is a general rule for everything.

C

What I'm saying is that the server going down for part of the information does not invalidate the rest of the information.

C

If you lose one logo, you still have the name, and so the the rcd passport should not fail verification because it's still correct it's just you shouldn't use some of the information that it references.

D

John agenda bash: we keep talking about this. This is a working group item. This is late. Let's skip connected identity and just do this. You know I've got a hard stop at five, but let's just keep going is that okay.

A

Chairs, uh do you think we're going to accomplish anything or are we going around circles, there's no point and continue to go around circles.

D

I think it's better to do this than talk about a non-working group item and a potential charter change.

D

Is it circles? I don't think this is circular. I think we're actually getting a lot of agreement. I mean, I think, this fundamental question of like what what actually counts as passport validation, is important and like if you know how we scope, passport, validation and understand. It is super important and I think we can resolve that.

D

I mean, I think I think, for example, we all pretty much agree that, like you know, if, if the json object's signature validates against the cert there's, you know and there's a level of passport validation in that I know when chris and I are corresponding about this um in the last couple weeks. You know one of the examples I posed to him when I was arguing. You know for uh jwt constraints. Being uh honored in these cases was like.

D

We wouldn't do this for, like level of better station right there's like a restriction that level of attestation, you know can't you can only sign like b and c or your permanent values and so on signs in a like. Even though the entire passport validates um I I argued, you shouldn't trust the origin desk. If that's true, do people roughly agree with that.

D

Sorry, do you mind, can I just repeat it.

C

Sorry, so so imagine that there's a passport.

D

And you know it has a jwt constraint in the cert, that's signing for it right and, let's not say it's a delegate, sir. Let's just take a hypothetical case where there's some gateway operator, who is only allowed to sign, b's and c's.

D

Let's say that that operator generates a shaken passport and like that chicken password has um an loa a lot of level of association of a in it like when that shows up at a verification service, and you know determining service provider like, should that entity reject, should that ned still trust the ridge and dust if the loa is an invalid value for jwt constraints, what do people think about that.

A

My tendency there is to think that the validating the constraints is part of validating the passport. I mean it's part of validating the signature. So even though I have a signature that that's there, if it's violating what's in the certificate, then you should not trust that you should not use that signature.

A

So I think I'm with you at that point.

D

This is different. I'm trying to tease out why this is different, I'm not convinced that it, it isn't different, but, like so alec and jack convince me it's not different.

J

It I think it really just comes down to the fact that this verification has to be performed at the end entity device the device that's going to consume, that url right. It has to be now it could be consumed, it could happen earlier, but it has to be consumed there. Otherwise, it's just too easy for someone to have a.

H

J

Where you know you request it, I give you the right url and then the device goes to request and I give it a different url. So you have to do it at the end. You could do it earlier, but it given that that's the way you know the integrity works. I I think it just makes sense to separate integrity, verification from the verification service right. What you're? What you're signing?

J

What you're verifying in the verification service is the integrity is, is a value you expect the integrity and the passport matches the integrity in the delegate cert if you're doing that kind of model, but not that the resource has the value that matches the integrity value, because that check is really intended to be done by the device. I mean they kind of so similar to sub resource integrity in a web browser.

J

You know a web browser may embed an html page from another website, but it's not going to check the integrity of of that iframe that it's embedding it's just going to pass that on to the client, because if it did and it worked that doesn't mean the client couldn't do the verification it has to be done in the client. I mean it. I guess that's just the way. I view it.

D

I mean yeah, you know again because I imagine the tsp is actually going to consume that, in addition to just verifying it right, I mean this. I I I totally agree and I've said this a million times so far I want it to be. I want those urls to reach the end user advice and for them to access them.

D

I doubt that will be the practical case and in fact the security association is going to terminate whether we logically consider it the vs or, if it's you know some modular component, that's like one step off from the vs after the vs has done its job. I don't want to argue architecturally about how we want to draw those boxes, but the security association is likely going to terminate at the terminating service provider. Or do you disagree with that.

J

I don't disagree with that and I would say if they do that, then they would be responsible for verifying the integrity. If you choose to do that, then go ahead, do it and you need to verify the integrity put in your own web server and then send that url down? If that's, what you're going to do, you need to verify the integrity, I'm just saying that may not be the model for everybody, and if that isn't the model that a given entity is using, you know, then they shouldn't be verifying.

J

It should be the downstream entity, whoever is consuming that url and displaying it or putting it in their own web server.

J

The last person to consume that url to de-reference it is the one who needs to verify it, whoever it is doesn't matter.

D

Who needs to other people, optionally might, but the person who needs to is that person.

J

And they optionally might, but if they choose to that, doesn't that shouldn't mean that there was we're assuming they're responsible, because we know it could have been changed. So we kind of need to take that caveat. You can, but it it's it doesn't.

J

It doesn't mean you're, relying you're liable for it and it, and it also.

J

I mean, I guess, I'm concerned it's inefficient, um so I hope people don't um and I hope we don't act like it- improves the security because it really doesn't to have them. Do it.

D

Yeah from a pure security perspective in terms of the relying party will do precisely the same redundant operations. I agree with that and I think.

C

Even further than that, like someone who's, not the end user of this, like what can they do with the information that it doesn't match like if someone, if, if the originating service provider or some tsp who's handing this entire shake and passport onto the end user, if they download this logo and go oh, it doesn't match the digest. What do they do like? There's, there's nothing. They can do at that point to change anything like the the rest of the rcd's. Information is still there and it's still valid.

C

They can't edit the rcd because it's signed, so their only option is just to keep hand it on down and just go. Oh that's! Gonna! That's gonna be wrong when the end user sees it like, of course, now they can fail that yes, but if they do, then you've lost the rcd of the rest of the rcd information like you've lost.

E

The name my thinking was similar to what you were saying, john, um although I I would.

E

I don't know if this is a great excuse but like where do we expect this to really fail, like even with shaken passports like it's going to be some like, you know, somebody used the wrong cert or is wrong wrong information and the the originator of that signature probably wants to know about it more from an operational point of view, an operational failure point of view than then they're actually trying to get away with, like you know, sending the wrong logo, or something like that.

E

So I think that's similar to what you're saying john, like you're, you're, just fundamentally doing the wrong thing and you shouldn't know about it until, but so that you fix it sooner rather than later, and is the osp the a good place to do that since the osp's? Probably you know the you know providing a service to the to the to the to the person that signed the uh passport originally.

E

So I'm not saying that's an argument to to be hard nosed about this, but it's one argument.

D

Fail a passport that you that won't validate if you're any intermediary, that's he's a passport and you believe it won't validate as you're looking at it, regardless of any shenanigans, might happen like after you forward it on right.

D

Like I mean any uh attestation elevation case, that is not considering rcd, um you know, if you don't think what you're getting from the enterprise is valid, you're you're going to fail the call right- and I think a lot of this- and this this is the subtle video I was racing about like out of station level constraints and in jwt constraints you know is just the the question of um you know if some part of it, if some constraint, that is not just a ridge and dust, the things that you know base passports are intended to communicate.

D

If that you think is um you, you have no reason to think that stuff is illegitimate, but if something else in the passport is broken, should you fail the whole passport wherever you are, that you're checking it in the call path, and this was what I was trying to convince chris of as far as I can tell I I think, usually yeah you should now the the only thing, that's a wrinkle to that that rcd introduces.

D

Is this question of dereferencing further links right that, like you, might not want to do along the way, and that can I could see getting kicked down to whoever the relying party is ultimately whether it's tsp network at the end point or something if all you're doing is your check is just saying: okay, like this jcl field, checks out early, you know like what whatever something like that and I'm not going to do any of the recursive like url generation within it. Like that's a can.

D

I can easily imagine people just lazily kicking, but I mean if somebody checks it and goes to the trouble to ascertain that there is something broken in it.

D

I mean: is it their obligation to continue to to pass the call- and I know this is in in part a legal like safe harbor question of who gets to block and why, but from a security perspective, if the passport, you know contains fundamental flaws that you believe shouldn't allow it being, you should should not allow it to be validated down the road I mean I I you know, I I think nip it in the butt right.

C

Yeah, I think what I'm saying is, though, that you shouldn't consider that a failed validation I think rcd is rcd, is fundamentally different in that some part of it can grow wrong, but you still want to keep the rest of it.

E

And well, I don't. I think it is a failed validation, but maybe can we go the other way then like it failed but okay to pass along? I don't know because I think not saying that it hasn't passed. Integrity still goes to the fundamental point of like you know. That passport is not valid.

E

I'm I'm saying.

C

C

um John just to let you know, there's quite a long delay between you, unmuting and us being able to hear you.

D

Yeah, I'm trying to mute and unmute and be responsible, I'm just saying like if the passport doesn't validate it's not valid, I mean again, I I have a really hard time. This is why I raised that loa example.

D

I have a really hard time thinking of a defensible security argument, that if the passport doesn't validate against aot constraints, or something like that that that it's valid that they that this passport's only partially valid, I'm going to trust the origin, the dust, even though the the iat is broken like we have no language in a24 or anywhere else that uh I think hints that that is possible. I.

C

Agree with you, I think, for everything other than rcdi. I completely agree with you. I think rcd is special.

J

Do you mean rcdi, or do you mean rcd urls, don't match our cdi? I think that's an important distinction, I'm not saying in the passport doesn't match. Delegate rcdi claim constraint that that's valid. That's totally invalid kill it it's it's. I don't want to dereference the urls to see if the contents of the urls match- and I and and I know we're you know we don't want to talk about an unlikely event of a server failure, but I guess I'm looking at it. I think it's highly likely and it's not a failure.

J

It's it's too slow for my verification service. I'm not going to wait for three seconds to dereference this url, where the end device might be willing to. Well, maybe that's, I guess that's what I'm concerned about is I it's not a failure. It's just it's too slow and we see this with certificates, which should you think would be faster than than I want our.

E

Cds, I wonder if there's a way we can get our cake and need it to like that. We say I mean. I think the point is that if the signature over the json object is valid, then you can pretty much trust the that information, but we just don't want to go to the next step. Maybe there's some way. We can creatively word it where I I'd rather like that's, why I was trying to say like?

E

Can we go the other way like you know, we don't want to say that if the integrity is broken that it's still valid, I don't think that's something we should say at all just fundamentally, but can we say like in a creative way?

E

You know like if you're only interested in partial information and xyz criteria like the signature, I guess maybe not xyz make the signatures. Okay, um can we say, can we call it something different or something like that.

D

I mean I can imagine some creative wording that along those lines, so it can't ever be the signatures broken. It can't ever be that the constraint was checked and didn't work. I can imagine some. You know some language that suggests that, like not, everybody is going to reference those uris and be capable of looking at the potential permitted values for them and that, as a consequence of that, you know those entities are are not doing full validation of rcd.

D

It would be something like that and that any you know we create like two: two categories of validation: there's a validation, that's specific to rcd. This is trying to speak to jack's, where, where I think jack is going anyway, um kind of two categories of validation of rcd, one where you actually are you're dereferencing, the sub uris for it and another way where you're not, and that when you're doing the first category, like you just you validate the json works the constraints.

D

As far as you know, there's no violation of constraint that you can see without looking at those urls, then there's a second category of validation and anyone actually relying on any of those urls or related stuff.

D

That is, you, know, embedded in those those sub url references like you can't rely on it unless you do the second category of validation and like that's something that we're effectively expecting the ultimate relying party be that the end-user device- or you know the charming service providers, verification service that sucks up um that and re-hosts it or whatever does it I mean jack- is that kind of what you're asking for.

A

I would like to jump in because I've been at the front of the queue for a while. I'm.

D

Sorry, ben, I don't have the keyboard.

A

I know I know uh I'm the one supposed to be watching thecube, but uh uh I was gonna suggest something like what you're saying and I was gonna- take it further and completely decouple passport verification from rcdi verification.

A

So we've got a passport verification that just says everything in the passport discovered by the signature is is covered by the signatures. But then we have this rcdi thing and of course we signed it. So it was covered by the signature and it is providing this mechanism to the relying party of the dereferenced material.

A

That that that they need to do as an additional valid verification, over and above the certificate validation, so right now, a valid certificate does not imply anything at all about the integrity of external material.

A

A failure of rcdi does not in any way impact the validity of the certificate.

C

um That's that's what I've yeah! That's! What I've been going for.

D

Failure of icdi does not in any way impact the the validation of the passport. You mean not the affiliation, the password.

A

D

The password I I yeah see phrasing it that way. I it does not pass my sniff test precisely that's saying like I can validate this and if it's broken it's okay, I can use the rest of the the password that that's that's the thing I don't want to say. That's the thing.

A

One of the things that jack has mentioned, I think that that we might have to consider there is the idea of a temporary brokenness versus some kind of permanent brokenness. You know if it was broken just because the server was slow versus it was broken because the data came back wrong.

D

Yeah yeah, I got that I mean I I I haven't meant to ignore alex's argument either about just the servers like slower unresponsive or whatever I mean those are. I think those are all valid points. I guess I'm looking at this much. What I want to do is be able to find two processes, one of which passport validates.

D

If there's you don't ever see, anything is broken in it because you're not even messing with that rcdi stuff right like if we anything we write this to me like I check this, and actually this doesn't validate, but I'm still going to pretend it's valid that that that language of that form makes me extremely uncomfortable and russ. Would you speculate that might make people in security area relatively uncomfortable, but but like language, it's like look. There's one set of checks.

D

You do when you don't care about that, rci stuff, right and then there's another deeper set of checks. You do when you do and like as somebody who is consuming this passport and validating it, you can either do one or the other, and like does does that. Is that sellable? Do you think is: is that close enough jack to what you're asking for and alec.

F

I think there's an interesting way to spin what you've just said, which is how about, if you fetch that information, it must match the check and then alex can just not fetch it.

J

Exactly I was going to suggest yeah. It basically decouple right, so you've got passport verification which does not mention ref dereferencing, the urls. There's nothing to do you know, that's you don't need to dereference urls you're, verifying the rcdi matches the delegate, cert and all this other stuff, but you're, not dereferencing urls, and then you've got okay. Now, it's time to de-reference the urls, you need to go de-reference it, and then you need to verify that it matches the provided integrity and they're independent processes, and you may have an entity that does both.

J

You may have an entity that does just one. uh They really have nothing to do with each other. I think that's the way we cover this.

A

So before I give up my hands up, I agree with what what ally just said, but I wanted to make another point too, is that the things alex said about uh needing to pass the intake the hash forward.

A

If you pass, the url forward needs to go in the security considerations in this document, because, basically the you know, if, if you just because I verified it now doesn't mean it's gonna be verified, 500 milliseconds from now, and if, for any reason you don't can't send that dash forward or your end user can't use that hash. Then you need to provide some other integrity mechanism to make sure no one messes with.

A

You that could be something like copying. Your.

E

A

D

A

Own managed website.

D

Even though we we suspect people will do that strongly, at least you and I do, then I'm not sure we want to tell them how to do it um or, like you know, offer that as like a standard practice again, we all want to get to the state where that isn't how this works. um So I I'd probably rather put some guidance that um dances around that and puts the right musts and must nots that that uh would constrain that without explicitly describing that as a practice and an rc word publish.

E

I'm fine with that yeah, maybe something about the fact that you can't separate the integrity and the rcd um when delivering it.

E

G

Right, the properties and so that buying.

E

Parties have the opportunity to do the integrity check.

C

I think the the question that is still online.

C

When describing whether or not an rcd passport is valid, whether that includes the fact that the digest matches what's at the urls, because from my point of view, including that in the definition of whether an rcd passport is valid, causes quite a few problems, because networks are complicated and like files and stuff can just mess up everything so that it might be invalid for one person valid for another.

C

So if you completely decouple the fact that the rcdi is matches, the urls from whether or not the rcd passport is valid, I feel like you're much more likely to get a much more reliable system and yeah.

E

But I I think we're acknowledging that you can separate it. I just think it's a matter of semantics of whether or not you call it.

E

You know fully validated because at the end of the day, the the creator of the rcd wanted to include that image right so like um it should be receivable and renderable, even though, like maybe some devices can't render images or or whatever else, but it is the intended I mean you know, I think what the center sends and the reason that they included integrity with an image is because that was the intent.

E

We should honor that somehow other, except for cases where either the device can't render images or those types of situations.

B

So we're getting very close to the time that we have allocated and john indicated he had a hard stop. um I think that we did get some traction and it's the kind of traction that's going to require people to go off and think about it and start to propose some text.

B

um I think we're going to need another interim before we get to 112 to come back and continue this conversation.

B

So sorry, john, if you think I'm wrong.

L

Plus, there's the the connected identity thing we didn't even get to that's true.

D

For me, some of you may have heard about this. Yes,.

B

Yeah, so um I I think I would like to target something. um Maybe second week of october.

B

Yeah, I think that would be good and, let's not wait. um I think we have enough inertia in this conversation that there's a good chance that we can keep the ball rolling um in email. I think we understand enough of where everybody is coming from, that the the impedance that email brings won't won't.

E

Right get too much in the way, and I have to um go through that text about the other topics anyway. So I'll try to put something out sooner rather than later.

A

I was just about to ask: is this the only real open issue, or are there still others.

E

Well, I think the other issues depend on me, providing clear text also anyways. So, um okay, I think the other ones are more well understood. Hopefully, if there is still discussion to be had um it's better to do it on new text, anyways.

B

We've got five minutes and I don't want to um throw those five minutes away. Is there anything that um we want to try to sum up if somebody want to take a a shot at where we are, or do you think that we've pretty much already captured it as best we can in the notes um what we've got.

C

I'd like to apologize towards the end, it's quite hard.

B

Jack, what you've done is quite useful. I really appreciate the effort that you put into it.

F

Yeah, I was about to say, don't apologize, I think we're sorting out something. That's important here. Yeah, absolutely.

J

I had one thing I wanted to mention just as an intro chris. I think I need to follow up with you on this. I I think maybe it might be worth mentioning or recommending vectorized images.

J

I think we've kind of been looking at with vendors and things is kind of what these images display are going to look like and kind of. It's having. You know a recommended square image. That's vectorized means you know you can put a round mask on it. A you know, square with rounded corners mask on it. You know you can resize it. I think otherwise these are just going to get messy when you actually go to implement them. So not nothing to discuss here, but maybe it's worth recommending because.

E

Well, I think actually the good thing is that's more in the zip core draft which we need to follow up on also. um So I think um I do have some image text in there to try to do that, but make sure you join the sip core list also alex. So we can talk about that issue because I think that's you know hopefully easier to extend. I will probably want to talk about whether it's optional or I meant you know. Okay, I haven't had a lot of discussion around that.

E

Actually, to be honest, so I think that's a good topic to discuss.

A

I put my hand up to say I'm a little bit nervous about that being defined at the itf layer level uh or at least in the general basics of how rcd works, because I can imagine rcd getting reused in some other context. That has very different display limitations.

A

So it almost seems to me like something that I don't know if it's ipn and I or some other group should be looking at maybe 3gbp.

E

I assume alec means like svg or something like that, which is pretty standardly, supported, at least on, like um you know, mobile phones and things like that. But um but I get your point then also.

J

That is what I meant svg.

E

I think it would be pretty pretty okay to just put svg in there um if everybody agrees, but we can have that discussion. Obviously.

F

Okay, we've got like one minute. Is there any last point someone anyone wants to make.

E

Well, it was a great discussion anyway thanks everyone for the discussion and thanks uh john, for giving up the time.

F

All right well.

D

My pleasure, as I said, kind of a weird day, as some of you may have heard,.

A

With all that,.

L

All right, thank you all.

L

L