[MINUTES] CCG VCs for Recognition 2026-03-24

This meeting of the Verifiable Credentials for Recognition working group
focused on addressing privacy and security considerations within the
specification, as well as discussing the final publication process. Key
discussions revolved around potential privacy harms from surveillance and
association, the use of unique identifiers, and the implications of issuer
impersonation. The group also debated appropriate validity periods for
recognition credentials and the nuances of managing this information,
particularly in relation to historical data and organizational changes. The
IPR commitment process for the newly published specification was also a
significant point of discussion, with efforts made to ensure all key
contributors fulfill their obligations.
Topics Covered:

   - *IPR Commitment:* The final community group specification has been
   published, and a critical step is for all primary editors and authors,
   including Isaac Henderson and David Chadwick, to make their Intellectual
   Property Rights (IPR) commitments. This is a prerequisite for moving the
   specification to the working group, and Isaac Henderson will ensure his
   organization completes the necessary steps.
   - *Privacy and Security Considerations (PR #61):* The team reviewed
   several AI-generated privacy and security considerations for the
   specification, including surveillance of individuals, issuer recognition as
   a tracking vector, and the use of metadata as unique identifiers.
   Discussions highlighted the need to consider selective disclosure as a
   mitigation for surveillance and the potential for harms by association
   through issuer lists.
   - *Publication of Sensitive Information:* The group discussed the risk
   of publishing sensitive information, particularly in the context of private
   groups, and how this can be mitigated. The conversation also touched upon
   the potential for verifiers to infer information about users based on the
   issuers of their credentials.
   - *Issuer Impersonation:* The security consideration of issuer
   impersonation was discussed, emphasizing the risk of verifier
   administrators being tricked into adding malicious or untrusted recognition
   lists. The need for appropriate bindings to protocols and user interactions
   to prevent such attacks was noted.
   - *Selecting Appropriate Validity Periods:* The meeting addressed the
   challenge of determining appropriate validity periods for verifiable
   recognition credentials, considering industry use cases and the need for
   both timely updates and efficient infrastructure. The importance of
   managing historical data and organizational changes, such as acquisitions
   or name changes, was also highlighted.

Action Items:

   - Isaac Henderson to ensure his organization completes the IPR
   commitment for the specification.
   - Manu Sporny to incorporate feedback on selective disclosure and harms
   by association into the privacy considerations section.
   - Manu Sporny to update section 4.2 (Issuer Impersonation) to include
   discussions on protocol bindings and user interactions.
   - Manu Sporny to raise an issue regarding the mechanism for stating when
   a recognized entity is valid between two dates.
   - The group will continue discussing privacy and security considerations
   starting from section 4.4 in the next meeting.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcs-for-recognition-2026-03-24.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcs-for-recognition-2026-03-24.mp4
*VCs for Recognition - 2026/03/24 10:59 EDT - Transcript* *Attendees*

Benjamin Young, Dave Longley, Dmitri Zagidulin, Elaine Wooton, Isaac
Henderson, Manu Sporny, Parth Bhatt
*Transcript*

Benjamin Young: Good morning.

Parth Bhatt: Hey Benjamin, good morning.

Benjamin Young: Hang on.

Manu Sporny: Hey, Benjamin.

Benjamin Young: I'll give you just a couple more minutes.

Benjamin Young: Okay, I think this is thanks for coming everybody. This is
the verifiable credentials for recognition, previously known as verifiable
issuers and verifiers. I see there's a couple PRs that just landed and it
looks like we've also got a few issues that got some attention in the last
week that we can get to. I was hoping Ted would make it because one of them
was his issue and most recently commented on by him. but we'll take the
poll requests first, I believe, and then maybe Ted will show up.

Benjamin Young: That sound all Okay. let's start with the one that is
slightly older. issue 61. Would you like me to screen share or just browse
along and I'll resize the window a bit?
00:05:00

Manu Sporny: All So, let's see. This one is our spec. let me go back.

Benjamin Young: Yeah,…

Manu Sporny: I forgot They just announced the IPR forum. So, maybe we
should make sure that everyone on this call kind of knows about that. Let
me get a link there that's for recognition.

Benjamin Young: that'd be good.

Manu Sporny: Let's see here's the link to make the commitment. Dish Bazaar
has already made the commitment, but we need to get David Chadwick, Isaac
Henderson, and anybody else, that was in that original rebooting group, but
that was 8 years ago to make that commitment. just in case they're going to
I don't think anyone's going to claim intellectual property over this, but
that link will help people sign up for it.

Manu Sporny: we just need to make sure that especially David and Isaac, on
behalf of Frownh Hoffer and on behalf of True Trust, end up making the
commitment and University of Kent make that commitment. So, that was topic
one was just the final publication has been done. Thank you very much,
Benjamin, for getting all that together. the final link is here. and that's
the static copy that everybody makes the patent commitments on. and then I
think we can start the process in the past. transferring the repository
over has happened in parallel to getting the commitments.

Manu Sporny: I think that's fine. Meaning we get whatever commitments we
get.

Benjamin Young: and Isaac just joined.

Manu Sporny: And then we have to warn the group if we're not getting a
commitment from one of the main editors or authors. so we need to
definitely stay after them. And that's largely David and they have to sign
this thing because they authored it a lot. great. I don't know if you can
see in the,…

Manu Sporny: let me rehat.

Isaac Henderson: Hi everyone.

Isaac Henderson: Sorry for delay. I was just Okay.

Manu Sporny: Hey, no problem. the final community group specification was
just published because you were one of the primary editors during that time
there's a IPR commitment that needs to be made and…

Isaac Henderson: Okay.

Manu Sporny: I just put the link into the chat channel about that. So if
you click on that hopefully you can make the commitment.

Manu Sporny: It's very important that you and…

Manu Sporny: David make the commitment before we can move it into the
working group.

Isaac Henderson: …

Isaac Henderson: I'm just trying to figure it out.

Benjamin Young: It should look more or…

Benjamin Young: less like this, but you'll see a form instead of the text
that I …

Isaac Henderson: commitments are only available to individual organizations
participated in the credentials community group. It says that maybe I can
share my screen.

Manu Sporny: Yeah. Do you see a little check box at the bottom?

Benjamin Young: that'd be fine. I was about to say the same.

Isaac Henderson: Can you see my screen?

Manu Sporny: You are not a CCG member, are you logged in? I guess the other
thing we can try is let's see…

Manu Sporny: if you go to this link that I'm about to put into chat. Yeah,
in that case,…

Isaac Henderson: Okay, I think our organization is part of W3C…

Isaac Henderson: but they're not part of this credential community group So
that's why I'm also trying to figure out so what's the way in around to get
there but yeah okay all Mhm.

Manu Sporny: you have to get your organization to join the credentials
community group. and then once they're joined, you have to get your
advisory committee representative to agree to the IPR release. and…
00:10:00

Isaac Henderson: Mhm. Yeah.

Manu Sporny: that's typically the process.

Manu Sporny: So that'll take you longer than we have time on the call to
kind of do…

Manu Sporny: but please make sure to do that because if we don't get that
clearance from you or your organization then no I mean mean the IPR
commitments it's frownher right I mean more than likely they'll give the
Okay.

Isaac Henderson: Or is it any other way that I can just give an okay or…

Isaac Henderson: is it not okay? Yeah. Yeah. Yeah. Yeah,…

Manu Sporny: It's just going to take a little bit more time, especially
since they're already a W3C member. They've done this for other things.

Isaac Henderson: that's true.

Manu Sporny: Okay.

Isaac Henderson: Mhm.

Manu Sporny: So it'll just, take you a while. And if you need help
connecting with your advisory committee representative, I can probably find
out who that is. Do you know who your AC rep is?

Isaac Henderson: Yeah, I know internally who's that one?

Manu Sporny: Okay. Okay, great.

Isaac Henderson: Yeah. Yeah.

Manu Sporny: So you just ask them that you need to make an IPR commitment
for this specification that you contributed to and…

Isaac Henderson: Okay,…

Manu Sporny: and then that's it. okay thank you Isaac.

Isaac Henderson: perfect. then I will take care of that and…

Manu Sporny: Okay I appreciate that.

Isaac Henderson: I will keep you updated in the coming weeks. Yeah. Yeah.

Manu Sporny: Okay so I think that's that Benjamin. and we can kind of go
back to processing PRs.

Benjamin Young: Yeah, thank you for that.

Benjamin Young: And Isaac, thanks for showing up today. It's timely. Here
we go. Yeah.

Manu Sporny: All so this item, has kind of multiple things going on. this
adds a number of privacy and security considerations to the specification.
So if we look at the preview and go to the privacy consideration section
three should probably be an appendix we will see there's a title and then
the kind of a description of the privacy risk that we should be discussing.
heads up this is all AI generated but I did take a look through every
single sentence and made adjustments and whatnot. though it did a pretty
good job At low level it's kind of like there's some stuff we should
probably discuss in here.

Manu Sporny: but this PR just establishes the sections these are the things
we want to talk about not any of the details on how we mitigate just
identifying here's some risks do we want to generalize do we not do these
prompt any other ideas of risks that we want to highlight so I thought we
might spend the majority of the call today going through all of these
things and then the security consideration section is the same if we start
at section 4.2 issuer impersonation. it's covered too. So we can go through
each one of these. So what I'd like to do on the call today is just talk
about each one and see what adjustments we want to make.

Manu Sporny: so I can, make those adjustments and then get this into the
spec just in its current form as like, hey, there's just issue markers.
We're going to elaborate on each one and then other PRs will convert those
issue markers over into the actual text. this is also somewhat intertwined
with the W3C security and privacy group wanting us to do a threat model. so
I have sent an email to them. Let me get a link to that.

Manu Sporny: here in the chat channel I've sent this email out to both the
security and privacy group asking them basically hey do you want us to do a
privacy and security consideration section or should we just do a threat
modeling section? and there's kind of a general plea there don't make us do
all of them because they're duplicative of one another and what exactly is
the plan moving forward and we haven't done an FPWD yet and if we just do a
threat model will that be acceptable to both the privacy and security group
that sort of thing.
00:15:00

Manu Sporny: So that's the other reason I didn't start typing, out a bunch
of stuff in security and privacy consideration section because we might end
up deleting this and converting it into a threat model. which is a more
involved process, and then there's a big question about does the threat
model go in the spec itself or is it go in a separate document? that sort
of thing. Let me stop there. if there are any questions on the private
security threat models conversation. All right. If not, then let's go back,
I guess, to the PR and go through these one by one. starting with the 31.

Manu Sporny: the surveillance of individuals okay so section 31
surveillance of individuals as recognized entities the privacy issue here
is that if for public entities it's not that big of a deal like if you are
a state government and you're publishing information about the agencies
within your state, you do that publicly, that's not really an issue.
however, if you've got a private social network of people that are in
vulnerable populations or like you just your family, like internal family,
chat, whatever.

Manu Sporny: and you have, recognition credentials for everyone in the
family or everyone in the vulnerable community. if you take that
information and you publish it publicly, that is a pretty big privacy
violation. and we could potentially see people, there being, signal closed
chats which then end up publishing the information so that is an example of
a privacy harm that could be created for small groups and we should
probably provide guidance. I think the financial stuff is later on
healthcare and finances later on but this is ba that's basically this item.
So should we change this?

Manu Sporny: Should we not include it? Does this trigger a different issue
of concern?

Isaac Henderson: I think it's a good point but I think if it depends upon
the scope and also how many use cases which deals with private people right
or for example people so I think it depends upon it comes to that point so
I think we good to consider depending on the use cases to have those
parameters or so then if you provide some way that by selective disclosure
or what not other means just disclose only those attributes or claims that
are publicly recognizable by which we could eliminate the surveillance or…

Isaac Henderson: any thoughts on

Manu Sporny: Yeah, that's a good point.

Manu Sporny: Yeah, I so selective disclosure as a mitigation you publish
part of the list if not all of the list. yeah, that's a good point. We
should or I'm going to take some notes here for section 3.1. suggest that
selective disclosure could provide some protection.

Isaac Henderson: Mhm. Yeah. That's

Manu Sporny: I think the thing I'm mostly concerned about here is people
are outed in a community or somebody, one person. So, selective disclosure
requires all the actors to be honest. whereas I think the privacy harm kind
of comes in when you have a dishonest actor within the community that then
publishes community information.

Manu Sporny: Go ahead, D.

Dave Longley: Yeah, I don't know that selective disclosure is a solution to
this particular problem…

Dave Longley: because what's being highlighted at least in my read is
there's reuse of something that was published for a different use. So
whatever you had disclosed would have the same problem. So I think this
risk is really more about whenever you share a credential, someone could
take the information in that credential and share it elsewhere. And if your
method of sharing the credential is not targeted with some kind of
constraints around it and terms of use, you're just publishing it
somewhere. It doesn't really matter whether you selectively disclose X
publish the whole thing.
00:20:00

Dave Longley: any information in that situation because you haven't done
anything to mitigate additional sharing of it in some way is subject to
these risks even if you had an agreement with some private group. it's the
same thing like it seems like this is a more general concern around if you
present your credential to some party they can turn around and share that
information and it's only becoming a greater risk because of the idea of
not having a target with whom you're presenting the credential having it I
mean And I get that we said that there's a private group that you're going
to share it with,…

Manu Sporny: Yeah.

Dave Longley: but it's really just about this concept of publication.

Isaac Henderson: Or I think the others ways to restrict just the public
information is just going to go into this credential,…

Isaac Henderson: because if it is planned to be stored publicly and
accessible via public web or whatn not. So think then we might need to
restrict. Okay, these are the information related to an entity so thereby
we avoid this PI information.

Manu Sporny: All right, I think that's enough for me to kind of at least
start writing something around here. real quick, a side note, Dimmitri, the
spec was just published as a final and we need you to do an IPR commitment,
at the link there,…

Manu Sporny: because of the education use case you kind of brought to the
group.

Dmitri Zagidulin: Sure.

Dmitri Zagidulin: Doing so right now.

Manu Sporny: Thank you very much, sir. Thank you.

Dmitri Zagidulin: There. Submitted.

Manu Sporny: All right. So, let's go back to Okay, so let's do section 32.
There's a lot of these to get through, so we're just gonna spend a little
bit of time on each one of them. let's see. Issuer recognition as a
tracking vector. I was a bit unsure about this one.

Manu Sporny: when you share, let me start off with if the verifier knows
who issued a credential to you, they can already kind of determine what
community you're a part of, and that can be dangerous in certain areas for
the verifier to know that. and in those instances, maybe what you should be
using is like a BBS. I'm a part of this, greater community. maximize the
herd privacy when you do a presentation. that's kind of what this has to do
with. so basically if you use a verifiable recognition credential and you
present it to a verifier, then the verifier knows what community you're a
part of. Again, if you exposing the issuer is the same kind of thing.

Manu Sporny: So if the issuer doesn't have, a certain amount of herd
privacy, same kind of thing can happen. I don't know if we should include
this because it's kind of in the same vein. but meaning if the verifier
knows the issuer of a credential then it pretty much knows and that issuer
doesn't have privacy among issuers in that ecosystem then the verifier kind
of knows you're part of a community. meaning if that issuer only operates
in specific country or a very specific state then the verifier has a pretty
strong signal that you're associated with that state in a way that reduces
your privacy.

Manu Sporny: So options here is we could just not include this or maybe
there's a take on this that's different than just knowing the issuer.
00:25:00

Dave Longley: With respect to group privacy here, I think what's being
learned is potentially that the issuer is part of something like this is
more like if you had a hierarchy Harchy and there was some intermediate
credential that the verifier had not seen about the issuer and when you
reveal who the issuer is, the verifier learns about that intermediate
certificate and then learn and then they know that they're the intermediate
certificate or credential links them up to the root recognition credential.

Dave Longley: None of that reveals in my view anything new about the holder
that isn't already revealed when the holder says here's my credential from
this issuer. That's the relationship the holder is with the new piece of
information hold is that the issuer is in some way related to this
recognition credential hierarchy. that seems like that is what's new. And
when you're doing this presentation, the verifier has already said if you
want to present anything I'm willing to accept, you must present from an
issuer that it will be recognized in this hierarchy. So none of that feels
really new.

Dave Longley: the piece of information that if we had some more zero
knowledge proof style things around issuer identifiers and so on that could
be elided here would be who this specific issuer was but that's not for
this spec and that's a different technology consideration so I don't know
that much new information is really happening There you go.

Manu Sporny: Yeah, I'm leaning towards just deleting it. it's not so
different that it's special to this spec, I don't

Dave Longley: Yeah, I think if we tried to crystallize this, the verifier
might learn that a particular issuer is as an example like an accredited
university and they didn't know that before and that's only because there's
a hierarchy of recognition credentials. but all that being said,…

Manu Sporny: Doesn't feel worth it to me. Okay.

Dave Longley: I don't know if I did skim these earlier, but I'm trying.
There was oblivious HTTP comes up. never mind. That's issue four. He'll
bring it there.

Manu Sporny: All right. Moving to section 3.3. this is basically saying
that some of the metadata in the recognition credential can be used as a
unique identifier to track you. So for example, if somebody uses a
recognized by URL with a fragment identifier in it or output validation
that has a very specific identifier that only you have anything else like
that, right?

Manu Sporny: any kind of external URL can be turned into a unique tracking
identifier and that is what this is about. you have to be aware that bad
issuers may try to do this to you especially for recognition credentials
that are kind of more focused to that issuer and into you. So if you as a
holder are like, "Hey, give me a recognition credential." And the issuer is
like, "I'm going to give you one that's very specific to you and that's
going to track you." It'll work, but it's highly specific to you. that
could be an attack vector.

Manu Sporny: and then the mitigation is like a wallet should make sure that
they're not dealing with credentials that have those kinds of tracking
things in there and you can detect it by seeing how often the URL is reused
and whatnot. go ahead Dave.
00:30:00

Dave Longley: When we write the text for this section, I think it should
more or less start with any other verifiable credential, an issuer can put
uniquely identifying information into the credential. And so you need to be
aware that that can happen and so on. there are specific fields for
expressing specific information in any credential and that's true here and
in any one of those places an issuer that's not respecting individual
privacy could do something like that. So it's not special to this spec…

Manu Sporny: Yeah.

Dave Longley: but we should highlight that can happen.

Dave Longley: And here you should be aware this is true for any kind of
credential. So be aware of that threat that an issuer could do that to you.

Manu Sporny: And I mean this kind of falls back into we already talk about
this in the base VC data model spec and the question is is there anything
new here?

Dave Longley: If we can link to it and that would be great. It would just
be,

Manu Sporny: Not really because we warn about unique identifiers in the VC
data model and we tell people that they should use oblivious HTTP to fetch
these things. And so is there anything special to recognition credentials
here?

Manu Sporny: I don't think so.

Dave Longley: I don't think so.

Dave Longley: I know that these things are linked, but do we have a
specific sentence that calls out all of the security and…

Dave Longley: privacy considerations in the VC data model apply to this
spec? Okay.

Manu Sporny: Yeah. Yeah.

Manu Sporny: If you scroll up Benjamin to the top of the right there,
readers urged to familiarize themselves with the general privacy advice
provided in.

Dave Longley: Yeah, it would be good for that text to save as those things
apply to this specification as well. Something like that. And then I think
that covers this issue.

Manu Sporny: Add to top of privacy and security. Let's send this back to
see data model. note that warning that there shouldn't be applied and be
heated as its

Manu Sporny: this specification. all right. So that's section 34 is next
and this is publication of sensitive EOS.

Dave Longley: Hold on. that covered the first issue there.

Dave Longley: There were two issues.

Manu Sporny: Yeah, we can.

Manu Sporny: Yeah, the second one is just like you can use a remote URL to
check, revocation, freshness, whatever tells you if it's being actively
used. It's the same kind of thing. if it's a unique URL. I guess even if
it's not a unique URL, you get some kind

Dave Longley: That is true. I don't know that we talk about so I'd like us
in this specification to make a distinction between an architecture where
the holder brings with them what is needed to meet the recognition
requirements of the verifier versus the holder just gives the tail the leaf
credential in a hierarchy over to the verifier and the verifier

Dave Longley: look and looks everything up about them in so doing leaking
information about that particular request that's going on at that time and
I thought issue 4 sort of could be related to that it's talking about
verifiers who were fetching updated recognition credentials but it would
also be verifiers who are trying to fill the gap between I was given this
now for example what they're doing with the federated identity stuff I
think is less privacy preserving. And so if they're going to go out and
talk to the federation and say, "Hey, you people help me connect this to
that." I think it would be better for the holder to do that because they're
not leaking to who the verifier is that they're presenting to. you're not
creating that connection if it happens in the other direction.

Manu Sporny: So maybe we should have a cy let's see new section to how
holder provided recognition credentials are more privacy preserving than
ones fetched by the credential issuer. Okay, and I think we have a separate
issue that's tracking that one as well, but that's fine.
00:35:00

Dave Longley: Yeah, you just said fetched by the recognition credential
issuer. Did you mean verifier?

Manu Sporny: Sorry. Fetched from the recognition credential issuer by the
verifier.

Dave Longley: Yeah, having the verifier in there is the key piece.

Manu Sporny: Yep. Okay.

Dave Longley: I come.

Manu Sporny: That's good. all right. 3.4. I think this is close to the same
thing as 31. it's not necessarily about the individual finding out that the
individual is a part of a community. I guess this is where you're like this
person again is a part of a vulnerable community because of all the other
entities in this list of recognized issuers these are all immigrant
population organizations that provide digital credentials to immigrant pro
populations right

Manu Sporny: versus these are organizations that provide credentials to
citizens. and I don't again it's kind of like if the issuer you kind of
know that and so that's not really different here. So it feels like

Dave Longley: This seems like it's all about issuers, which is fine. but is
it about revealing associations that people might not have otherwise known
about or creating associative reputational harm because you happen to be on
the same list as some other party or…

Dave Longley: group and someone frowns upon that worse

Manu Sporny: I mean all those things.

Manu Sporny: But again, it's kind of like I don't know if this technology
really

Dave Longley: I think there's probably something worth mentioning in this
spec since the functionality of this spec is to highlight which issuers are
recognized by certain entities so that verifiers that can use that
information to make decisions. And that doesn't if you're just thinking
about it in a vacuum like that, you're not going to necessarily be thinking
about how if you build certain groups and lists of things that you might
create associations that have these additional effects.

Dave Longley: So that might be worth mentioning in some way that people
will look at the lists on their own and look at the relationships and…

Manu Sporny: Mhm.

Dave Longley: things that are put together in these lists to possibly guess
or learn information both about the types of entities people decide to
recognize. So you could look at this as a mass media sort of thing. some
mass media party puts out a recognition credential and they only recognize
some particular slanted news providers or whatever it is. And so that
creates some impression of that and some impression of them that maybe they
didn't mean to imply or there's additional information and things that are
learned by that just by creating that grouping.

Dave Longley: And that's so we should probably mention that additional
information or impressions or it could be true or false information could
be gained from just the kinds of lists and…

Dave Longley: groups and associations people put together.
00:40:00

Manu Sporny: Yeah, I guess I'll say harms by association or…

Manu Sporny: harms by issuer association. okay, I'll update that. All
moving on to security considerations. 4.1 was already there. 4.2 is the new
one. so for 4.2 to issuer impersonation. This has to do since these are
decentralized anyone managing verifier software can choose to include any
one of these lists in the software. So you don't have to pick one. You
don't have to defer authority to someone else. you can go in and you can
say, when I will take credentials from one of these verifiable recognition
lists."

Manu Sporny: and then you start adding a bunch because there's a human in
the loop there, the human might not vet the links or credential properly
and might, experience something akin to a fishing attack where you're like,
I know who this issue is. I trust them." But if you actually look at the
URL or the did or something like that, it's totally not who you think it
is, right? it's just some other entity and they have put out a recognition
credential to trick verifiers into using their list versus somebody else's
and then all of a sudden you're just letting anyone through your verifier
because you've got a bad issue in there. Go ahead.

Dave Longley: Yeah, I wonder if this should also talk about appropriate
bindings to protocols and user interactions. So I could imagine that the
users receiving a request from some origin. it would be good if they have
in their wallet somehow something that says yeah, I have a recognition
credential for an issuer at this origin or this issuer.

Dave Longley: if there's a check that's made that binds the request is
indeed coming from that origin when TLS was used to fetch the information
and so on. And then that's compared against the origin that's expressed in
the verifiable recognition credential or something along those lines. it
would be good for this section to talk about how protocols can do things
like bind those kinds of information together so that software can help
users make better decisions.

Manu Sporny: typing it down. Goods for section talk about how protocols can
information be together to help the rules not all scam I can make that
update. And this feels, and part of it is I'm kind of like, I couldn't
imagine that there's a class of couldn't imagine, but I doubt there's going
to be a class of fishing attack where you're trying to trick administrators
into adding the wrong recognition list in. These things are probably going
to be fairly well known in their ecosystems. but maybe not.

Manu Sporny: Okay, 43. moving on to the next one. Selecting appropriate
validity periods. This is just like what should the validity period for
your verifiable recognition credential be? 10 minutes is probably too
little, but we probably can't suggest it should be exactly one week because
use cases vary from industry to industry. so this is just saying, hey, make
sure you pick an appropriate validity period for your ecosystem. If you
pick something that's too long, then you might remove an issuer, and that
issuer is going to continue to be recognized for a long time, and and at
the same time, you don't want it to be so short that your infrastructure
hit on a very regular basis. go ahead, Dimmitri.

Dmitri Zagidulin: Yeah, this is always a tough topic, I agree with
everything that you said and it intersects with the organizational end of
life question…
00:45:00

Manu Sporny: Mhm.

Dmitri Zagidulin: and personal I suppose because the issuer can easily
close their doors. We don't want to say this diploma the recognition
credential is your entire lifetime. We want so the presenter brings
everything has to interact with our other modes which is you ask a
directory of whe whether this issue is currently or was at some point in
history valid. So ju just wanted for everyone to keep that in mind. the
organizational end of life questions that intersect with bring your own
recognition credential. We need both.

Manu Sporny: Yes, that's an excellent point.

Manu Sporny: Go ahead, Dave.

Dave Longley: I think one way to make the decision on…

Dave Longley: how long the validity period ought to be also has to do with
how large and diverse the list is. it becomes if you want a shorter
validity period for a larger and more diverse list that you might even want
it to be 24 or 48 hours, you up this on a regular basis and the entities
that use this list you make sure that they know that they can go fetch, the
latest one.

Dave Longley: and that allows for different recognized parties in there to
be removed as needed on a regular basis which you're not going to be able
to do if you make your validity period a long time. And then there's other
ways to sort of deal with the list changing problem. I guess I should
mention you also want to be able to add entities to that list. So I would
expect you to want to have a fair for a large and diverse list a fairly
short period 24 48 hours. and I think we could probably make a
recommendation like that. if you're also looking to manage lists that are
changing in size and so on or make them more decentralized, we could talk
about how it would be good to have lists that have aggregators.

Dave Longley: your list just has aggregators, accreditation bodies and so
on it. Those are much more likely to be stable. So, you could have longer
validity periods, though we should maybe discuss what the benefit of even
having a really long validity period would be. and then you issue
individual credentials that the accreditation credentials to other parties
and those can be more easily revoked or have shorter periods. but we really
should probably talk about what is the utility of having a much longer
period so that people could understand why you would even want to go more
than 24 or 48 hours.

Manu Sporny: Also very good points. two thoughts. One of them is I don't
think we have a mechanism to say this issuer was valid between these two
time frames. I think we could potentially do it via a reg x in the JSON
schema on the date. but I don't think that works.

Manu Sporny: Does JSON schema have a date range thingy? Jason Yeah.

Dmitri Zagidulin: I have a

Benjamin Young: Not sure about a range,…

Benjamin Young: but it does have a format…

Manu Sporny: I mean the problem with format is that it's like I don't maybe
there Can you reg x ranges?

Manu Sporny: It feels like you can

Benjamin Young: if you're defining it as ISO 8601 that's got a range format
in it which you could write reg x against which I think is what the injent
schema is defined as is 8601 but demetri you had

Dmitri Zagidulin: No. Yeah.

Dmitri Zagidulin: So we can do some basic reg x though that gets wild with
leap years and leap months and stuff. so it basically treats dates as
string only with everything that comes with it. they sort of assume that
basically date ranges are business logic not schema logic. I know there's
been some discussion on the spec itself about ranges but it didn't really
go anywhere.
00:50:00

Dave Longley: So I did not check the JSON schema spec but one of the more
popular libraries A AJV has examples using format minimum and maximum both
with inclusive and exclusive options for dates.

Dave Longley: So I think you can do exactly this.

Benjamin Young: And it also looks like they have a discrete duration type
for encoding the ISO8601 duration format…

Benjamin Young: which uses a slash between two dates.

Manu Sporny: I am So heard on the AG AJV thing, but we can't point to a
spec, right? It's not in the spec. And then Benjamin, I'm trying to figure
out what the JSON schema for that duration thing would look like because
does it support the slash stuff…

Benjamin Young: All right. Yeah.

Manu Sporny: because I know the P3 those durations but they're not anchored
in anything, it's like the JSON schema that we have in the spec today just
checks against the credential and the credential has it's XML datetime not
ISO8601 but I think they're close enough for it to work. I don't know…

Manu Sporny: I don't know if does it have slash support, I guess, is the
question. Draft 2019.

Benjamin Young: Yeah, we'd have to check the drafts.

Manu Sporny: Yeah. Yeah.

Benjamin Young: They only reference in the documentation I just linked to,
they only reference the P format.

Manu Sporny: And the P format wouldn't work then. Yeah. So, it looks like
the AJV thing is the thing that we would probably need to define. Unless we
were to say from valid until for that very specific entity. But we can't
make those types of statements with the mechanism we have right now. I
don't think okay something let me raise an issue on this because I don't
think we need an answer for this.

Manu Sporny: So how do you state recognized entity is valid between two
dates.

Benjamin Young: All right, dude.

Manu Sporny: A historical action.

Dave Longley: Yeah, I don't think saying that the entity itself is valid
between two dates is even necessarily what is wanted. it depends on issuing
and verifying, for issuing, I think you would want it on the action and
would be bound to the particular credential that's being issued.

Dave Longley: and not every credential that's issued necessarily even has
validity periods on it. and then there's a different consideration for I
don't think you would need this for the directory case where you'd say this
information is only valid from period to this time period. is I peed?

Manu Sporny: I'm thinking of the diploma use case.

Dmitri Zagidulin: Why is that? You do need because remember we need to
capture a key history right like that key got rotated and we want to say
that it was valid during this time.
00:55:00

Dave Longley: Yeah, but we're not talking about keys there.

Dave Longley: We're just talking about I don't know, it's probably hard to
find in screen share the directory example right now, but the directory
just these are properties about this identifier. And so it would have to be
the case that these properties only applied to this identifier. it's like
somebody sold or abandoned their did or something like that would be the
use case.

Dmitri Zagidulin: Yeah. or…

Dmitri Zagidulin: or the company got acquired or renamed, right? I think
the validity period is super important for this stuff.

Manu Sporny: Yep. …

Manu Sporny: I raised an issue.

Dave Longley: …

Dave Longley: we should raise the issue, but in my head, I'm thinking so
the use case for this would have to be that you're putting out a
recognition credential where for the directory case, you're putting out a
directory you're making just directory claims about something and the
validity period for your recognition credential would have to be different
for what you're expressing in the directory information. And so it's like
you're putting out a recognition credential for historical information for
a certain period. Is that right?

Dmitri Zagidulin: Yes.

Dave Longley: And I'm wondering how weird that'll get if you're issuing a
recognition credential that is valid, let's say, this year, but ory
information says you're talking about a party the directory information is
valid for 1970.

Manu Sporny: All right.

Dave Longley: So I think we have a lot to tease out in these scenarios.

Manu Sporny: I raised issue 63 and then Benjamin, back over to you because
we're out of time for today.

Benjamin Young: Yes, we are.

Benjamin Young: Do we want to pick up from here at 4.4 or we have the is
Okay.

Manu Sporny: Yeah, we got to keep going.

Benjamin Young: So, we'll pick up from 4.4 next week. Probably do these
three and then back to PRs and issues if that sounds all right. Okay,
thanks everybody and see you in a week.

Isaac Henderson: Thank you.
Meeting ended after 01:00:45 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*