[MINUTES] CCG Incubation 2025-10-01

Meeting Summary

*Meeting Title:* CCG Incubation - 2025/10/01 10:58 EDT - Transcript

*Attendees:* Benjamin Young, Dave Longley, David Chadwick, Dmitri
Zagidulin, Hiroyuki Sano, John's Notetaker, Kayode Ezike, Manu Sporny,
Parth Bhatt, Phillip Long, Ted Thibodeau Jr, Tom Jones

*Summary:*

The meeting focused on use cases for the verifiable issuers verifier spec
and the associated data models.

*Topics Covered:*

   - *Credential Refresh:* Discussion of the "credential refresh" feature,
   including a refresh service property and a refresh credential to be added
   to the specification.
   - *Verifiable Issuers and Verifiers:*
      - Review of the "KYB" (Know Your Business) use case, focusing on
      entity description and metadata, with a data model example from Dmitri
      Zagidulin.
      - Discussion of a fully decentralized verifiable issuer use case.
      - Refinement of the data model for the decentralized use case, with a
      focus on "verifiable recognition credential" and related properties.
      - Exploration of verifier-side use cases and how to specify criteria
      for what a verifier is allowed to request.
      - Consideration of protocol and query language agnosticism and the
      impact of JSON schema and presentation schema on flexibility and
complexity.

*Key Points:*

   - *Credential Refresh:* The refresh credential feature is ready for
   promotion and will be reviewed next week.
   - *KYB Use Case:* Dmitri Zagidulin to create a data model to capture the
   KYC entity information.
   - *Decentralized Use Case:*
      - The use case focused on recognition credentials and constraints on
      their use.
      - The term "accreditor" was replaced with "recognizer".
      - The group discussed appropriate recognition criteria.
   - *Verifiers:* The group agreed to keep the data model layer to define
   the format of what verifiers can request.
   - *Next Steps:* David Chadwick is to submit a use case and data model.
   The group will continue to review the use cases and associated data models.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2025-10-01.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2025-10-01.mp4
*CCG Incubation - 2025/10/01 10:58 EDT - Transcript* *Attendees*

Benjamin Young, Dave Longley, David Chadwick, Dmitri Zagidulin, Hiroyuki
Sano, John's Notetaker, Kayode Ezike, Manu Sporny, Parth Bhatt, Phillip
Long, Ted Thibodeau Jr, Tom Jones
*Transcript*

Manu Sporny: All right, let's go ahead and get started. We have at least a
core group here. welcome to the incubation call. we do have an agenda
today. and that is to continue to focus on the use cases for the verifiable
issuers verifier spec and minimum viable data models that cover each use
case. that is primarily what we're focusing on today. there are some other
items that we do need to cover. which I let's see it's the other specs
we're incubating. So there are a couple other items that were added that I
want to make sure that we're aware of. I think largely around credential
refresh.

Manu Sporny: so, we should spend a little bit of time at the beginning of
the call kind of talking about that and just see if we're okay to promote
that to the standards track and then, go from there. Any other updates or
changes to the agenda? Anything else we want to discuss today? All right.
then let's go ahead and get started. let me bring up we have a set of specs
that are ready that we've agreed already for promotion. and then we have a
set that are not quite there yet. A credential refresh was on this list.

Manu Sporny: it needed a refresh which has been done in the refresh service
property. So we're trying to use kind of a service endpoint based approach.
Same kind of thing that you would put in a DID document. for the refresh
service there were the manual ref Those errors have been fixed now. where
we show the entire a manual refresh flow and then a full output of a
automatic refresh flow. and that so that's been completed. the other item
we mentioned was that it would be nice to have a refresh credential.

Manu Sporny: The refresh credential is for effectively use cases where for
example you don't have selective disclosure and you don't really want to
share the refresh service. So the issuer has decided that putting the
refresh service in the credential itself is not what they would prefer or
it can be selectively disclosed away. and therefore every presentation of
the credential exposes the refresh service, which could potentially open
the issuer up to a DOS attack. I'll note that they're probably going to
need to protect themselves against, attacks like that anyway.
00:05:00

Manu Sporny: but there might be a reason that they don't want to use the
refresh service property and they want to give a credential that is kind of
kept private. So the holder just keeps it in their wallet. They don't show
it to anyone except when they want to refresh the set of credentials that
they have. the refresh credential could have and this is the data modeling
here is not So we might want to change this but the idea here is that you a
You as a holder would get a refresh credential. It might list one or more
verifiable credentials that could be refreshed here. It might refer to them
by ID.

Manu Sporny: it might refer to them by a hash value. and then there could
be a refresh service here. A different way we could model this is put the
refresh service in with every, VC kind of stub. but the core concept here
is that we may want to give people refresh credentials that they can then
use to do the refreshing instead of embedding it directly in the VC itself.
So, that's the last item that I think this spec needed before, we say it's
ready for promotion. let me pause there and see if we've got any feedback
or input. Has anybody been able to review the specs since we added these
things? Go ahead, Dave.

Dave Longley: I just wanted to mention some other use cases that at some
point we should figure out where to document them. But the other use cases
for using a separate refresh credential include refreshing other things.
You might present a credential to refresh some other items that aren't
necessarily verifiable credentials depending on your use case. You might be
refreshing multiple VCs as tokens. you might be refreshing a bundle of
several VCs and so you might want to have a refresh credential that's
separate from that you submit it and you receive some bundle of some number
of other credentials and then there are use cases where putting the refresh
service in the VC might create a size issue you might have very small VCs
that you need to refresh those might be transmitted over wireless or as
barcodes or whatever it is they might go over a small

Dave Longley: data channel. And to get those, you don't want to also
include the refresh service in that piece of information. And you wouldn't
be able to selectively disclose it either.

Manu Sporny: Plus one to all those use cases. We really should write those
down in the document primarily because we're going to be forced to do that
when we ask for the horizontal review on your first item Dave refreshing
other things. Zcaps are very much in mind for that. there are Zcaps only
last they typically have expiration dates. they expire, you want to be able
to refresh them. And ideally, we'd have a mechanism to do that. the refresh
credential is one such mechanism that you could use to list a bunch of
ZCAPS and refresh them and that credential can have confidence methods so
that you can provide different ways of doing kind of cryptographic
authentication during the refresh.

Manu Sporny: So again that's why this credential class exists is because
there's a set of use cases where the refresh service property doesn't make
a lot of sense. Okay. Any other thoughts or feedback on refresh credential?
given that this was just added, we should give folks a couple of a week or
so to take a look at it. and then I think the proposal is going to be to
move this into a specification ready for promotion. Meaning we're done as
much as we want to be with it here and then VCWG can pull it in and then
decide what the next steps are with it.
00:10:00

Manu Sporny: so I know I said we'd make that decision this week, but
because we just added something to the spec, I thought we need to give
people a little bit of time to take a look at it. so next week, we'll ask
the question on whether or not we think it's ready for promotion. All
right. last call. any other discussions folks want to have about any of the
other specs that we're incubating before we move into verifiable issuers
and verifiers. then let's move into verifiable issuers and verifiers.

Manu Sporny: the ask last time was that folks would raise issues or PRs for
their use cases. So Dimmitri, you had one, David Chadwick had one. and then
I said I'd raise the decentralized one. go ahead, Dmitri.

Dmitri Zagidulin: Manu, I really appreciate you also pinging with a
reminder to do that. I just have not had an opportunity to do that yet.
deeply apologize. in the conversation kicked off internally at DCC a whole
bunch of related arguments and discussions and I'm still working on it
basically.

Manu Sporny: Okay, thanks Demetri.

Manu Sporny: Do you have a data model in the KYC? I know you pulled up an
example of it. We could just pull that up. I think that might be good thing
to discuss.

Dmitri Zagidulin: Yes. …

Dmitri Zagidulin: give me a second. I'm actually looking for it right now.
go ahead while I pull it up.

Manu Sporny: Okay. let's start with that use case. Demetri, I'll try to
give some background on it. So the use case is basically KYB, your
organization, whatever you want to call it. so there's a list of entities
that have undergone some level of vetting by an organization or person that
you trust and you want to basically get that list.

Manu Sporny: the use case around that is you want to be able to show some
extra information about the issuer. So maybe the verifiable credential only
has the issuer URL in it or the issuer URL in the proof. could be SID
whatever. and you've got this identifier and you want to be able to enrich
the display with some more trustworthy or trusted information. and so I
think that's the first use case. And so I think Dimmitri is finding the
data model that they currently use at dcc to provide that information.

Dmitri Zagidulin: Yeah. Give me a moment. So, this is an example here in
Google chat. I can share screen if

Manu Sporny: Yeah, please. Yep,

Dmitri Zagidulin: All right.

Dmitri Zagidulin: So this is the current entity description that gets
returned from the implemented dcc issue registry. So you fetch a did and it
gets back and again the data model is extremely simple. The organization
name

Dmitri Zagidulin: there's a legal name for the organization which is often
different from the regular organization name homepage URI and a logo.
there's also some other arbitrary metadata identifiers in other databases
for that same entity. And that's it for the moment. So that there's also a
way to get all of the entities in a given registry. that there isn't a way
to get the metadata details in line and based on number of privacy concerns
that we talked about earlier that may be a decent addition. That's it.
00:15:00

Manu Sporny: Got it. okay, that sounds good. And I guess Dimmitri, are you
looking for us to have because I mean, there's already data model here and
there URLs and all that kind of stuff.

Manu Sporny: Is what you're looking for an equivalent data model in the
thing that we're creating?

Dmitri Zagidulin: I'd love to be able to see a mapping at very least,…

Dmitri Zagidulin: I'd love to see a data model that has homepage, logo, and
legal name and a map of other identifiers.

Manu Sporny: Got it. sounds good. okay. I mean, I think we've got Yeah,…

Manu Sporny: I think Okay, so this is helpful, So, there's a minimum viable
data model here and what we need is to show some kind of mapping to it.

Dmitri Zagidulin: Yeah. Yeah.

Manu Sporny: All Cool. that's helpful. anything else you want to cover
here, Dimmitri?

Dmitri Zagidulin: So, I said, it's very bare bones. so I don't think it's a
super heavy lift on a heavy ask on the verified insurance verifiers back.

Manu Sporny: Yeah, plus one to that. I don't think we're going to have any
problem. I think these base properties are needed for everything else that
we're doing in it.

Dmitri Zagidulin: Yeah. Yeah, I figured. Yeah.

Manu Sporny: So, Okay, that is super helpful. if you don't mind,…

Manu Sporny: Demetri, could you read an issue and copy and…

Dmitri Zagidulin: Yes. Yes.

Manu Sporny: paste that into it?

Dmitri Zagidulin: I'll do that right now.

Manu Sporny:

Manu Sporny: And then I'll switch to the other I raised an issue for the
fully decentralized use case. So let me try to get that on screen. all
right so here's the fully decentralized verifiable issuer use so something
like this Dimmitri would be good. okay.

Dmitri Zagidulin: You got it.

Manu Sporny: So what we have here is the fully decentralized verifiable
issuer use case. I tried to just focus on the issuer part of it. It should
work for verifiers as well. so the base use case is the national college
board would like to provide a verifiable credential to each state college
to confirm that they would accept degrees issued by a specific college as
legitimate proof of education. since the national college board does not
operate technical infrastructure with high availability guarantees.

Manu Sporny: it wants to distribute this information in a way that can be
presented by the state college issuer or by the holder of a particular
degree when presenting that degree to a verifier. So this is the
decentralized case. and then there's a proposed minimum viable data model
for achieving the use case which is effectively the same thing that we put
in the pull request that failed to get consensus to be pulled in. I tried
playing around with some of the language here. So there is this verifiable
ro credential here as part of the type. I stuck with the accredititor
language here. I know we're a bit on the fence about that.

Manu Sporny: but this is effectively the entity that's saying that they
would trust credentials issued by there's a credential subject. It
identifies an issuer. I renamed this from accredited something or another
to acceptable action. So this accredititor views these things as acceptable
actions. So the action is issuance and the whatever is issued has to match
this credential schema and the acceptable action can happen between these
time periods. and then this is a bachelor's degree, this is a master's
degree and then there's a digital signature on the proof and that's the
entirety of the minimum viable data model.
00:20:00

Manu Sporny: let me pause there. See if there's any input on that. Go
ahead, Dave.

Dave Longley: One piece of input here is I have an intuition that this
feels like an access control list and that's also sort of fits into
authority models and authorization models and I think we wanted to avoid
that. So seeing roles and acceptable actions feels like that can be
confused again with authorization lists and that sort of thing. So I don't
know that it's quite the right language. I think the concepts are close to
being right but it feels more like you would read this and say I will allow
you to issue as opposed to if you've issued these credentials I will accept
these from you which is an important distinction. fun.

Manu Sporny: Yeah, plus one to that. I don't know where to go with the
language for this. I agree that there's a problem confusing this with
ourbacks. because that's not definitely not what we're trying to express
here, it's an acknowledgement not a authorization.

Manu Sporny: Go ahead, Phil.

Phillip Long: Yeah, I was just wondering…

Phillip Long: if maybe the notion of recognition I mean essentially what
you're saying is if someone sends me this credential then it is recognized
that is something that is from an institution that we have already
authorized or recognized as having the permission to do this and therefore
somebody else should recognize it as Well, and then under the acceptable
actions is the constraints of the recognition. Just an idea.

Manu Sporny: No, I like that. let's go down that path a bit more, Phil. So,
what would we change the type to here? a verifiable recognition credential.

Phillip Long: Yes. Yes.

Manu Sporny: All verifiable recognition. So, I recognize that entity. And
then this is you mentioned constraint Yep.

Phillip Long: These are constraints on the recognition. Yeah, I don't know
how else to say that, but you're basically saying this is recognized
pertinent if the following things are presented in that credential. Yeah.

Manu Sporny: So, recognition constraint or…

Dave Longley: If we Yeah.

Manu Sporny: something like that. no. That you just typed that out. Okay.
Okay.

Dave Longley: Yeah. If we don't have a better name, let's roll with that
for now.

Manu Sporny: All let me just edit this in place.

Manu Sporny: So this is verifiable re recognition credential. This is a
recognition constraint.

Phillip Long: constraints. …

Manu Sporny: Recognition constraint.

Phillip Long: it could be criteria.

Manu Sporny: Recognition. what do people like better?

Manu Sporny: Criteria or constraint? All right.

Dave Longley: They both have weirdness with plurality,…

Dave Longley: but the criteria is fine.

Phillip Long: That's just because we speak English.

Manu Sporny: Yeah. okay. I mean, that works for me.

Manu Sporny: Does anyone really not like that or

Dave Longley: The only question I would have would be when we want to
express that you would so I don't know how the flip side of this the
verification piece goes that you would and that piece is a little bit weird
and maybe we just don't worry about it right now but there is the flip side
of this this isn't the decentralized verifier user issue use case, but
we're going to have a flip for this for verification, I assume, where
because people have stated that they want to have these lists that say it
would be good for people to announce entities that they think should be
given information or…

Dave Longley: something like that. yeah.

Manu Sporny: Yeah. let's just gen up an example for a verifier and…

Manu Sporny: then that might help us work through that. Is that what you're
Okay.

Dave Longley: I'm just wondering if it will work for that as well.

Manu Sporny: So, let's go through that. Before we do that though, What is
this entity called? do we just want to call it an issuer of the recognition
credential or A creditor is not Probably right.

Dave Longley: Do we need this extra term it might help in the spec, but do
we need it? Yeah, I let's not put it in the data model.

Manu Sporny: What is it?
00:25:00

Dave Longley: …

Phillip Long: Yeah. There's cat.

Dave Longley: the term accredititor,…

Manu Sporny: I'm just trying to Yeah.

Dave Longley: I think you could just put issuer in there. I don't think
anyone can issue these Right.

Manu Sporny: Here's the sure and then now people are confused between this
issue and this issue. That's what I was trying to get around is to use
language that provided it.

Dave Longley: Just in that case just put recognizer or something like that.

Manu Sporny: Okay, that sounded super weird and awkward to me, but that's
fine. we can do that. there's got to be a better word for that. But good
enough for all right. So, let's work on the verifier side of this.

Manu Sporny: and while we're choosing this use case for an issuer and
minimum vi for a verifier. So still a recognition credential. You've still
got a recognizer. This is going the credential subject's going to be a
verifier. The type is verifier.

Manu Sporny: recognition criteria that verification.

Dave Longley: So, what's being recognized? you can't be recognizing the
right for someone to request information because anyone has the right to do
so what is being recognized?

Manu Sporny: from specific information from you.

Dave Longley:

Dave Longley: Let's see. It's like you're recognizing that they will handle
certain types of information in respectful ways.

Phillip Long: aren't you actually recognizing that the credential that's
been presented is one that whatever this group is called that issue it has
done so following the guidelines of the agency or entity that they have to
get permission from to make these issu to issue these credentials. So
you're actually checking to see if this minimum set of credential data
elements we're not calling it a creditor but we're calling it the
recognizers.

Phillip Long: Requirements.

Dave Longley: That sounds like the issuance case to me though. everything
you described there makes a whole lot of sense to me for the issuing case.

Phillip Long: Yeah, I'm having trouble making that switching from the lens
of the verifier,…

Phillip Long: I have to say.

Dave Longley: Yeah, I think in this case we're trying to enable people to
publish these or…

Dave Longley: to issue these recognition credentials where they're
recognizing that they would trust other parties to request certain kinds of
information and…

Phillip Long: question. Yeah.

Dave Longley: treat it in a privacy respecting manner. Yeah, it's more like
you're just requesting the information.

Manu Sporny: It's a type verification these are based on the actions right…

Manu Sporny: but I recognize that this entity

Dave Longley: I know we don't want to deviate too far from the core roles
in the VCDM, but you're recognizing that they can request and will handle
data certain kinds of data appropriately. They're an appropriate data
handler and…

Dave Longley: data requester.

Manu Sporny: and…

Manu Sporny: I'm getting very specific. This is wrong, but they're allowed
to make a verifiable presentation request for and you could even explicitly
state they're recognized as man it is very much allowed in the EU though.

Dave Longley: Don't say oud. Yeah. But this design is too,…

Manu Sporny: Yeah, we don't know.

Dave Longley: we have to cover both cases. you can model this in an
authoritative way by saying you've got to use my list for the people…

Manu Sporny: Mhm. Yeah.

Dave Longley: who I have recognized as data handlers. But it doesn't have
to be that way across the entire ecosystem. So we wanted to work for
everyone.
00:30:00

Manu Sporny: Go ahead, David. Oof.

David Chadwick: First of all, apologies for being late. I've been for my
annual COVID and flu jab today with the NHS and the queue was horrendous. I
should have been back an hour ago. but everybody was queuing up to get
their free jabs. so that's why I apologize for being late. yeah. So What
does that mean? a verification presentation request means presumably you
can send a VP request…

David Chadwick: but what does verification mean?

Manu Sporny: We're trying to figure that out right now,…

Manu Sporny: David. So, we're trying to work on the verifier side of we're
working on the decentralized use case…

David Chadwick: Yeah. Mhm.

Manu Sporny: where the specific use case is for the verif we said maybe
this is a verifiable recognition credential I recognize you to do these
things like I as an individual recognize you David to do these things. I
would set you as the subject here. I would say that you're a verifier.

Manu Sporny: So, you're playing the role of a verifier, and I recognize
that you might try to verify a bachelor's degree, master's degree.

Manu Sporny: And so, we're trying to figure out this recognition criteria
like how do we express that I recognize that you can I recognize you for,
verifying bachelor's and master's degrees.

David Chadwick: …

David Chadwick: so let me say how we modeled this and implemented this
previously. It was that we recognize you You are going to send a
verification request to the wallet to the user and you're only trusted if
you like to ask for this set of particular credentials and how you specify
that is in the request criteria and…

Manu Sporny: Mhm.

David Chadwick: we used the diff model because diff had a standard for
making requests, and so we said this is the diff request that you're
allowed to send. and the reason for this is that t you're trusted to be a
verifier. but then we trust you to ask for a degree certificate or
something or this and a birth certificate, but then once they're trusted,
they ask for a whole bunch of other things. And then there's a privacy
issue there.

David Chadwick: If a verifier is going to randomly ask for loads of
information from the user, that's definitely against GDPR.

Manu Sporny: Mhm. Yes.

David Chadwick: So what we were constraining was the shape of the
presentation request that you could make. And so you didn't want the schema
because the point is he might be asking for two or three credentials and he
might say I want your passport or your driving license and I want your bank
statement or I want your credit card statement. Do you understand? So it's
not a schema that's constrained. It's the actual presentation request
syntax.

Manu Sporny: And so, just right before you joined, we had, a verifiable
presentation request in here as one of the things we could do.

Manu Sporny: I do agree that, yeah, there are certain verifiers that are
going to only be authorized to ask your, and I'm using the word authorized
because I'm talking about the EU use case. So, they're going to be certain
ones that are only authorized to ask you for age information. And then
there are others that are going to be able to ask you for your national ID
number and a whole bunch of other stuff. and in I guess we need to figure
out what the target of these recognized criteria Is it the presentation
request and then it's like Is it VPR? Is it something else? or do we want
to Yeah. how do we specify what they're allowed to ask for? Go ahead, Dave.

David Chadwick: In my opinion, it would be you'd say the protocol and the
query format. So, because now in our particular case, we only had one
because we were implementing open ID for VCs. so we didn't need to specify
the protocol because that was a given. All the implementations were using
that standard protocol. but then we specified the diff presentation request
that they were allowed to give. But now we've got more of an open model. I
think there might be more than one protocol and that also besides the diff
presentation request that's been sort of I won't say blacklisted but it's
been frowned upon by the open ID group and they've got their own query
format now.
00:35:00

David Chadwick: So you would put in their query format. This is what
they're so I think it should be the protocol and the query that you're
allowed to send.

Manu Sporny: Okay. …

Dave Longley: I'm on the queue.

Manu Sporny: thank you, Dave Longley, you're up.

Dave Longley: I do have a response to that too, but I'm on the queue to say
maybe we want verifier. And the same for issuer to be a recognized issuer.
It's a little more explicit in what this is. We might also want to be
explicit and have a recognized by field. And you could repeat the issuer's
value in there, but that allows you to do things like combine these into a
single graph of information. where you might combine all of the recognized
verifiers and issuers together, but you would still want to know, you would
do the checking on that they came from VCs, but then you would merge this
information together and you could see who they were actually recognized
by. so I would recommend that and we can edit the other one too if we want
to make those changes there too.

Dave Longley: but with respect to whether or not we should put the protocol
in here. I think quickly that might become a problem especially if there
are other protocols and so on. And I wonder if what we have here actually
already handles what we need it to handle. the credential schema that's
listed there in the issuer example might be for the full credential,
everything that could appear. But what you could put in the recognized
verifier case is you could have a different schema in there that will
operate on a credential again, but it might have something like additional
properties false for whatever area of the credential that they're not
allowed to ask for those things requiring selective disclosure or so on.
And if you do it like that, I'm pretty sure it won't matter what the
protocol or query is used to request that credential.

Dave Longley: you're just applying it to what the output would be. that
doesn't give you certain advantages like being able to look at a request
immediately when it arrives and decide to reject it. You have to do some
work to produce what the credential would be first, then look at it and
say, you're not allowed to ask for that." From a user experience
perspective, nothing's going to change. I wouldn't think. but the digital
wallets would have to do a little bit more work to do it that way. But the
advantage of doing it that way is we don't have to know anything about any
protocols here. it's still a credential schema. It's just a different one.

Dave Longley: It's redacted bachelor's.json or limited. it's something that
might not have all of the properties.

Manu Sporny: Okay, thanks Dave.

Manu Sporny: David Chadwick, go ahead.

David Chadwick: Yeah, unfortunately I think that's too simplistic because
that's thinking the verifier is only asking for a single credential but
verifiers can ask for multiple credentials and they can ask for either or
credentials and that's what the query format provides. That's why you say
is this query you can launch. so yours is not good enough, J. You would
just repeat the entire query format if you were going to say this
credential schema or this credential with this schema. So you just end up
repeating the queries that have already been formulated by the protocol

Dave Longley: So to respond to that, my view of how this would work would
be you would digest whatever recognized verifier inputs you would want.
Each one of those would come with the various credentials that would be
acceptable. You would receive a query for some kind of information. You
would produce a possible presentation and then you would go and see you
would go and fetch all of the credential schemas for the verifier that made
the request and apply them to every credential in the presentation to make
sure that at least one of that there was a passing schema for each
credential that's in the presentation. And if you do it that way, it fully
covers multiple credentials. I believe and it seems to me like it covers
all of the use cases without involving any protocol information.
00:40:00

Manu Sporny: Go ahead, David.

David Chadwick: Yeah, unfortunately that doesn't cover GDPR then because
the example I gave was passport or driving license and bank statement or
credit card statement. You'd have to put four credentials in there. Whereas
in fact, you're only authorizing the verifier to get two, but you'd have
four in there. So, it could then go and ask for four and it would conform
to your model. but it would actually break GDPR because the guy's asking
for too

Manu Sporny: I don't know if that's true, David. but I'll get to that.
going back, I do like the idea that we would create a mechanism that is
protocol and query language agnostic. I think that's pretty important.
because there are more and more protocols that are being put out there to
move data around. and if we can get to it being able to just select
constrain on the data model that's being shared the verifier has asked for
this amount of data. I have prepared this package of information.

Manu Sporny: I'm going to send Does it match the recognized verifier
criteria that I have for this verifier? If we do it at the data model
layer, then we remove an enormous amount of complexity at the protocol
layer and the query format layer, right? I think we can potentially solve
it at that layer, but it is I mean I'm sure you guys have seen the most
recent DAL queries and the queries where you're asking for multiple things
across multiple formats. They're gigantic queries, and then we would have
to iterate all over all the variations of those queries.

Manu Sporny: so I am a bit concerned about the higher up on the stack we go
and if we pull in the protocols and the query languages that has a chance
of getting really complicated and then oifying our ability to innovate in
the query languages and the protocols meaning you'll just get locked in.
the verifier can only ask for this information in one way and then you're
now beholden to this recognized entity to update the different query
languages or the different protocols that are allowable and that are just
oifies if they don't have the ability to do that.

Manu Sporny: So I am really concerned about us putting the query languages
and the protocols into the recognition criteria because of potential
oification that can happen that will almost certainly happen and the amount
of complexity that there is at that layer. that's it. go ahead Dave

Dave Longley: Yeah, there are probably other ways we could meet the use
case David has where you should only be presenting one of these and that
could be done for example through a presentation schema instead of a
credential schema could be an option. which keeps things with the data
model that doesn't really care what the protocol is. I think we could do it
that way. Other opt we could invent other options here where we talk about
we could do things like give this credential scheas ids and say you can
have a combination of these. but I think if we do a presentation schema,
that might be the cleanest way to do it.

Dave Longley: and then you can put any kind of different combinations of
things in there and you're going to apply that schema to the presentation
that's created totally ignoring whatever protocol details were used to
originally build that and request the credentials.

Manu Sporny: Go ahead, David.

David Chadwick: Yeah, I like what you said, Manu, about the data model and
keeping the data model there and trying to avoid the protocol. I like that.
I think that's nice and clean. And what you're effectively saying is we
don't really care how you ask for what you want, but what we're saying is
this is all you can have, and so what we'd have to have in here is some way
of this is all you can have and it be you can have two from these four or
you can have one from these three or whatever. we will be duplicating the
query language in some respects in order to do that but it keeps it at the
level of the data. do like that idea and I think that concept is a good one.
00:45:00

Manu Sporny: Okay, much appreciated David. yes. I think so. If we look at
Jason schema and going back to the use case you highlighted David about,
you can have, one of these two documents and one of these other two
documents, but not all four documents at the same time. I agree that's an
important use case. and you can create constructs like that in JSON schema
has the oneoff mechanisms. You can deeply nest those so that you can do one
of one document from this set and one document from that other set. so I
think that we have a potential solution here's the problem though.

Manu Sporny: JSON schema cannot look deeply into enveloped presentations
unless we define some way of unwrapping the envelope presentation. Maybe
that's what we have to do. but I'm wondering…

Manu Sporny: What about for M do?

Dave Longley: I don't think we need Can I jump Q?

Dave Longley: We need to do that. I don't know that it matters be as long
as you're using a verifiable presentation. if the way you secure that is
add an envelope afterwards, then the schema is applied before you add the
envelope. if there are it becomes challenging…

Manu Sporny: What about for binary M do Yep.

Dave Longley: if there's no mapping from a particular envelope to a
verifiable presentation. But as long as there's a mapping from one to the
other, then you can apply the schema.

Manu Sporny: I am concerned about that though, but because in reality,
someone's going to ask for, an MDOC plus education credential. we're
starting to see stuff like that pop up, right?

Manu Sporny: and I guess what you're saying is that there will have to be
some mechanism to map from the Seabore MDOC to some kind of JSON E format
so that the schema can match against it and that's true of anything like if
this whole concept of recognition criteria that M do. Seabour people aren't
going to have to solve that problem.

Manu Sporny: because they're going to run into the exact same problem that
David just mentioned, which is what happens when somebody asks for an M dot
plus an education credential that's in VC format. How do you do the match
against that, and then the amount of complexity to have a seabore, schema
and versus a JSON schema is just this stuff the complexity explodes if you
go in a variety of different directions. but I think that's helping us here
is we can see certain paths here where the complexity explodes with even
the simplest use case.

Manu Sporny: And that helps us kind of back off from, those paths, which
again is why I think maybe us focusing on the data model layer helps us
avoid that explosion in complexity around query languages and…

Manu Sporny: and protocols. but Yep.

Dave Longley: And you can I was just going to say and…

Dave Longley: you can solve these problems once with a single mapping. if
you try to bake this at this layer to these recogn recognition credentials
and so on, everyone pays the price for that complexity.

Manu Sporny: Yeah, that's right. Yeah.

Manu Sporny: so if someone wants to ask for an MDOC and an education
credential at the same time, which again looks like it's going to be a use
case, the binary MDOC folks are going to need to figure out a way to map
that to a JSON object. there are ways of doing it, but it's going to be
mandatory that you do that so that this layer of the stack doesn't get
crazy complicated. what do we get to? We'll need to refine this a bit more.
This is a verifiable recognition credential. This is a verifier. We don't
know about the recognized by property. We need to come back and talk about
that.
00:50:00

Manu Sporny: We're calling this recognition criteria. I don't think we
figured out if what the type is yet. but we think presentation schema might
be the best way to express what a verifier can kind of ask for. Is that
where we are? I'm going to just save that temporarily and we'll come back
around to this. David Chadwick for next week. we're raising issues, here,
use cases. So, we've got Dimmitri's list of known KYC entities use case use
case and then a data model.

Manu Sporny: We've got the fully decentralized use case here with example
minimum data model. If you could raise one for your use case that would
help us kind of get to three use cases and three minimum data models that
we could then move into the spec and start refining. so if you could add an
issue ne by next week,

Manu Sporny: David, just detailing the use cases or use case you want to
focus on and then the minimum viable data model for that. sure thing.

David Chadwick: Yeah, sorry.

David Chadwick: I meant to do that this week, but got caught up with a
number of health things, so I didn't

Manu Sporny: Okay, no problem. we'll come back to it next week and then
hopefully by next week we will have a set of use cases.

Manu Sporny: We'll have some minimum data model and then that will allow us
to have a focused discussion on what's the minimum data model that we need
in the spec to achieve all of these things. okay, that's thank you
everyone. We made good progress today. I really appreciate the discussion.
we'll meet again next week and keep going on this stuff. okay, that's it
for the call this week. thanks again. Have a wonderful rest of your week
and we will meet again next week. Take care.
Meeting ended after 00:52:51 👋

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