[MINUTES] CCG Incubation 2025-10-15

Meeting Summary

This was the Credentials Community Group (CCG) Incubation call held on
October 15th, 2025. The primary focus of the meeting was to discuss
community updates, including the status of ongoing work items, and to
address the upcoming conflict in meeting times due to the launch of the
Verifiable Credentials Working Group. Key topics and points discussed are
below.
Topics Covered

   - *Community Updates:*
      - The Render Method and Confidence Method have been successfully
      moved to the Verifiable Credentials Working Group.
      - The Technical Plenary is coming up and the next W3C working group
      charter will be discussed in Coobe Japan.
   - *Call Time Discussion:*
      - Due to conflicts with other groups, the call time is being moved to
      Thursdays at 10:00 AM Eastern, starting the week after next
(October 30th).
   - *Use Case Discussion:*
      - Discussion of use cases, including the "know your issuer" KYC use
      case, the fully decentralized use case, and the authoritative list use
      case, initiated last meeting.
      - David C presented a pull request with a technical change.
   - *Credential Refresh:*
      - A discussion about moving credential refresh to the ready state.
   - *Verifiable Issuers and Verifiers:*
      - Discussion on updates related to use cases, specifically concerning
      the role of wallet providers.

Key Points

   - *Call Time Change:* The meeting time will change to Thursdays at 10:00
   AM Eastern, starting on October 30th, 2025.
   - *Wallet Trust and EU Regulations:*
      - There was considerable discussion around the concept of "trusted
      wallets" and wallet attestations, particularly in light of EU
regulations.
      - Consensus was reached that wallet attestations fit within the
      existing architecture for verifiable credentials.
      - Concerns were raised about wallet attestations and the potential
      for anti-competitive practices.
   - *Closed Ecosystem Use Case:* It was suggested to frame the wallet
   attestation use case as a "closed ecosystem" use case to clarify its
   context.
   - *Use Case Review:* The group agreed to review existing use cases, as
   some may be outdated or duplicative.
   - *Minimum Viable Example:* A discussion around what constitutes a
   "minimum viable" example for the spec.
   - *Action Items:*
      - David C was asked to update the PR.
      - The group will focus on properties needed in the data model to
      support use cases.
      - Manu Sporny will raise a PR.
      - Dmitri will raise a PR.

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

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

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

Manu Sporny: All right. Hey everyone, let's go ahead and get started. this
is the credentials community group incubation call. it is October 15th,
2025. we do have an agenda today. on our agenda is discussing any community
updates including the status of the promotion work items. we are now in
direct conflict with there are a lot of these calls happening primarily
because we've incubated things those have moved forward those calls are
meeting more regularly the verifiable credential working group is going to
start meeting more regularly and did working group and special topic calls
are meeting more regularly which means that typically the

Manu Sporny: 10:00 a.m. and 11:00 a.m. time slots start filling up. so
we've got a four-way conflict between the existing calls and we need to
move something because we have successfully incubated a number of things
and moved them over. This call is becoming less and less a high priority.
meaning that the incubated items that we've moved now onto the standards
track those are the things that we need to focus on and move forward. and
then we can continue incubating the things that we're incubating here. but
today we're going to talk about where can we move this to that other people
can make the call so that we can meet more regularly and not conflict with
the other calls.

Manu Sporny: So we'll have a discussion on changing the call time. and then
we will look at pull requests related to use cases. and that were discussed
last time and do some general issue processing. and if we don't have enough
of that going on today, then we'll end early. are there any other updates
to the agenda? Any other changes, things of interest that folks would like
to cover? If not, let's go ahead and jump into community updates. I did
mention that we had successfully transitioned the render method and the
confidence method into the verifiable credentials working group.

Manu Sporny: So those are now official work items. They are on the
standards track and we are going to start meeting regularly to move those
two items forward. that call has been scheduled for the exact same time as
this call right now. So we'll have a discussion about changing the call
time, but we have a conflict here. but the good news is that that's on the
standards track and we're going to be moving that forward. the other I
guess community news is that The technical plenary is coming up. there will
be a discussion on the next W3C working group charter during that meeting
in Coobe Japan.
00:05:00

Manu Sporny: and hopefully we'll have a proposed u charter that's it at a
high level. any other community updates that are relevant to All right.
moving on to the next item. call time. So I mentioned that the verifiable
credential working group is going to start meeting more regularly. they are
going to meet at this exact time which means that most of us are going to
disappear into that other call. we could move this call to Thursdays at
10:00 a.m. Eastern.

Manu Sporny: so it's going to be an hour earlier than this and it's going
to be a day later than this. would anybody not be able to make that call
that is contributing significantly to the work items? So specifically, if
you are contributing to the quantum safe crypto suites, the verifiable
issuers and verifiers or Zcaps, can you not Zcaps. We're going to have to
figure out something else to do with ZCAPS, but really it's verifiable
issuers and verifiers and quantum safe crypto suites are the two that are
left in incubation. Would you not be able to attend Thursdays at 10:00 a.m.
Eastern? I need to check with Dimmitri. He'd be the only other person that
might have an issue with that. So, let's reschedu these calls.

Manu Sporny: starting the week after because next week is the internet
identity workshop and there are going to be a lot of people gone so the
week after next we will start having the call at the new call time. I will
reschedu the calls accordingly. okay, thank you for that. next up, pull
requests related to use cases identified and discussed last time. just as a
reminder to everyone, the discussion we had last time was around the three
kind of general use cases. the Dimmitri's kind of know your issuer KYC use
case.

Manu Sporny: the fully decentralized use case and the authoritative list
use case. go ahead, David. You've got your hand up.

David C: Yeah, I was just looking at my calendar when you said the revised
time on the 30th of October, which is the week after next. On Thursday,
we've got a VCW respect refinement meeting.

Manu Sporny: That's a conflicting call. That's the one that we need to
move. So, we'd move that call to this time slot and…

David C: Okay.

Manu Sporny: we'd move this call to that other time slot.

David C: Okay. I missed that bit. Okay. that's all I was raising.

Manu Sporny: Thank Yep. Yeah, that was the call we needed to move.
Dimmitri, we're rescheduling this call and we're trying to find out if 10
a.m. on Thursday eastern would work for you for the incubation call.
Dimmitri, I don't know if you're talking,…

Dmitri Zagidulin: One second.

Manu Sporny: but you might. There you go.

Dmitri Zagidulin: One second. looking on the calendar. I think this coming
Thursday as in tomorrow would be difficult. yes,…

Manu Sporny: No, no, no. Yeah, not next week because next week's IW, but
the following week, that's when we'd start moving them to 10 a.m.

Dmitri Zagidulin: That works for me.

Manu Sporny: All Sounds good. So, we'll get those rescheduled things. going
back to kind of the discussion that we're having, we're trying to hone in
on the core use cases we want to create the data model for and kind of have
that discussion. we had three that I mentioned. so let's go ahead and pick
up that conversation again. let me see.

Manu Sporny: I was not able to raise any PRs I am jumping ahead. I wanted
to cover the promotion work items. jumping back. During the last call, we
had asked folks to take a look at credential refresh. A couple folks does I
think we're basically like this is done with incubation the general bones
of it already. and we were going to move it up to specifications ready for
promotion so that the working group could take it over and take it the rest
of the way. we said we'd do that move this week. are there any objections
to kind of moving it to the ready state?
00:10:00

Manu Sporny: So, we'll move it to the ready state. That doesn't mean We can
continue to make changes on it. and the only point at which we have to stop
working on it is if the VCWG adopts it as a new part of their charter. so,
that's good. That means that we're basically down to kind of three specs
that we're continuing to and really I expect us to largely focus on
verifiable issuers and verifiers. because we're not seeing a lot of
movement on the quantum safe crypto suites and Demetri, I think the ZCAP
thing is potentially going to be another call that's a little more focused.

Manu Sporny: So our job here is to finish up verifiable issuers and
verifiers to a point at which we're happy with And with that now let's move
over to ble issuers and verifiables and verifiers. so here is the spec and
let me pull requests. looks like we do have use case updates. David, you
opened a PR. So, let's go ahead and go over this. is there any background
you'd like to give us on this, David, before we go forward? Go ahead.

David C: Yeah so I made really a technical change to the existing
documentation which really was that it didn't mention about wallet
providers because there needs to be trust in the wallet that the user is
holding and so that's the third category of trust that I've added. what Ted
has done is Ted has made quite a lot of comments on my PR, but most of his
comments are actually about stylistic and grammatical changes to the
original text, not to my technical changes.

David C: So I would kindly ask Ted to make a separate PR in which he just
puts all his grammatical and stylistic English changes in one PR and that
can be done too easy and then this one should just concentrate on the
technical changes rather than these grammatical and stylistic changes which
because otherwise Ted's changes to my PR seem to you can't see the wood for
the trees if you know what I mean. it's swamping it. So, that's a comment
I'd wanted to make. and the main change is I said to add a third category
of trusted entity.

Manu Sporny: All right. Dimmitri, you were on the queue. I don't know if
you took yourself off or…

Dmitri Zagidulin: Yeah, I took myself off. I wanted to make a comment that
pushing back against the notion of having to trust a wallet, but it doesn't
really matter for this discussion.

Manu Sporny: Okay, I was going to say the same thing. let's go back to the
stylistic stuff, though. David, it's fairly easy for you to integrate these
if I mean Ted usually does an excellent job at fixing grammar and…

Manu Sporny: syntax and all you need to do is just add suggestion to batch
for all of them and then that'll integrate it.

David C: No, I think something it may constantly don't work.

David C: It didn't work or something. Okay.

Manu Sporny: Do you want me to do it? It's fairly easy for me to do it.

David C: Okay. if you want. Yeah. Yeah,…

Manu Sporny: Did you find any of them? I mean, they all look fairly
straightforward. and then what that does, David, is it just cleans it up.
So, we're back to a clean Yep.
00:15:00

David C: I wanted so we could just concentrate on the technical change
really and I've added an actual use case of where the trusted wallet comes
in because it is something that the European community working on in their
EUDI European digital identity wallet

Manu Sporny: Yeah. All right. So, that should collapse everything.

Manu Sporny: which it did. Demetri, did you want to go with the wallet
comment? I'll follow you.

Dmitri Zagidulin: So yeah, two things. one is as always the idea that the
wallet has to be trusted is against the whole trust model of the verifiable
credential data model. But that is a battle that we lost in Europe is
requiring it. And so to that effect the way they're requiring it is by
asking wallet credential attestations which just means that the wallet
vendor is another issuer. Right? So in that sense it's no different from
any other verifiable credential issuer.

Manu Sporny: Yeah, a plus one to that. I think the EU has made a really bad
mistake. I think they are setting themselves up for elimination of a free
market for open wallets. with this approach, I think we should say
something about how bad it's going to be when it comes to wallet out of
stations. to be clear we don't require web browsers to have addistations at
all today and the world's on fire but for different reasons right so there
is no reason that a wallet needs to have an addestation I think part of
this a very positive view of this is that people haven't realized that yet
and when they do they will back off

Manu Sporny: fun wallet attestations. A more cynical view is that there are
vendors that are getting in there because they know that this is a barrier
that a lot of open wallets will not be able to hit. and because of that it
will constrain competition in the ecosystem. we use web browsers today.
Websites don't ask the web browser to identify itself. that is a very good
thing. The trust model for verifiable credentials doesn't require this. so
I'd prefer to if we say something I'd prefer us to not say that this is an
anti-attern right and again this spec is probably not the place to do it.

Manu Sporny: but I also understand, David, that, the EU has gone this way
and they're requiring it and all that kind of stuff. I cannot support this
concept. It's just so poisonous to the ecosystem. So David, if you want to
keep the language in there, maybe we could add an issue marker to say that
there is not consensus around while data station being a good idea. Even
though UD has decided to go that route, I think there are a couple of other
things that have been decided there that I think are just anti-atterns when
it comes to verifiable credentials. go ahead Dave.

Dave Longley: Yeah, big plus one to everything you said there. having to
trust a wallet is an antiattern. It does not fit in with the trust model of
verifiable credentials and I think that's a big misunderstanding in some of
the European work. That being said, the way that this can be done because
anyone can be an issuer, a wallet provider can be an issuer and you can
design a system where you issue credentials. Some third party is some
accreditation body for wallets and they can issue credentials to wallets
and wallets can be forced in some places to present those credentials.
00:20:00

Dave Longley: And none of that's a good idea, but you can do it all. And
you could do it with the way that this spec was already written. And if I
agree that this is probably not the right spec to call out that wallets
that this is all an antiattern, but I also don't think that the spec should
call out and say, "Hey, you should do this with a wallet." if we want to
have some language in here, we can say I think we probably have to address
both sides of it. We have to say currently in some places there are people
looking to issue credentials to wallets and require those wallets to
present them. in those cases the wallet plays the role of either issuer or
verifier or the third party that credit accredits them as an issuer and the
wallet presents some other credential that they have from them.

Dave Longley: something along those lines and ideally it just goes in an
appendix so it's out of the way of the main spec I don't think we have to
architecturally do anything to support that anti- pattern

Manu Sporny: Go ahead, David.

David C: Yeah, I mean years ago I had the same view as the rest of you, but
the arguments that were posited for having trusted wallets was that
basically it's there to protect dumb users. So that issuers will check that
the user has got a bonafide wallet that's not going to leak information.
It's not going to, subterraneously push his credentials off to some third
party or whatever. you got a wallet that's been issued by North Korea, And
everything you put in it gets sent off to North Korea and the users
completely oblivious to this because it's just some free wallet that he got
that gave him some goodies like, 50 pound Amazon voucher.

David C: so that was the argument I heard for why you want to accredit
wallets. So, I thought that had some credibility and was worth mention the
other thing to mention is that lists of trusted issuers and verifiers are
all optional anyway, right? You don't have to abide by ban them. you can
actually take a credential from anybody and you can send it to anybody.

David C: So some ecosystems can be built with no trusted lists right so to
actually use the argument that we don't need to be forced to use a trusted
wallet list is no different to the argument that we don't need to have a
trusted issuer list or trusted verif r r ruling it out and I do agree that
it can easily be implemented

David C: as the wallet supplier gets a credential from an issuer to say
yeah you're a trusted issuer of wallets and here's a verifiable credential
for you so in terms of technology the underlying infrastructure approach in
it will be the same and in fact there was a big argument in the open ID
connect group that I participated I mean I've stopped participating now but

David C: should this attestation be different from the same as credentials?
And I think when I finished participating the majority of the viewpoint was
that the attestation should just be a normal standard credential and can be
asked for by the verifier or the issuer just like any other credential. So
technically wise it shouldn't affect the infrastructure. Okay. That's my
two penalty.

Manu Sporny: Yep, appreciate that. David, I think we have consensus that,
if you have to do this, it just fits into the existing architecture. Me
meaning that, we can call it out in some way, but I think what we're saying
is we're not saying this is a totally different system that you need for
wallet out of station. You can just use a digital credential to do it. the
delivery mechanism is the same thing. It goes over the same existing
protocols that exist. and it can fall into the same issuer model there. and
if you want to have a list of issuers that provide wallet addations you can
do that with the verifiable issuers verifiers list. and because of that we
don't need to call it out unless we want to make it a point to call it out.
00:25:00

Manu Sporny: meaning there's no new normative spec text that needs to be
written. so that's Point two though is this whole argument that it's for
your protection. we should get rid of end toend encryption too because it's
for your protection because criminals use it to do illicit things. I don't
think people need to be babysat, I think that the whole wallet out of
station thing feels like coddling the user beyond what they need. people
make choices today on what pieces of software that they use without this
thing in place, especially I mean just it's the entire app ecosystem, right?

Manu Sporny: I mean why don't we have add astations for every single type
of app you should not be using that grocery list app or because people
could figure out your buying habits right or you shouldn't use that word
processing application because who knows where it came from the argument
just its and I'm not saying you're making this argument David I'm saying
that the argument it just plain does not hold water. we don't need it for
any of the other apps that we have today. You could argue that it's sort of
in place through the app store and things like that, right?

Manu Sporny: I mean, the North Korea digital wallet is probably not going
to make its way into the app store. And if it does, it's not going to
survive there for long if the security researcher finds out it's doing bad
things. we don't have these sorts of protections on websites. this is a
legitimate website signal other than, the standard signals that, the
browser manufacturers put in there. But that's all voluntary stuff. No one
said that this needs to be a fundamental underpinning for the internet and
the web.

Manu Sporny: I think that still holds and we probably need to start saying
something about this more loudly before what happened to the web payments
ecosystem happens to this ecosystem which is the large tech providers did
an equivalent version of this for payment wallets. and it led to no
competition. and luckily kind of the death of that particular set of
standards that would have established that. but again this is just I find
the whole concept completely unacceptable. We should probably be more loud
about it.

Manu Sporny: Maybe we should, start a thread on the credentials community
group mailing list about it to just signal that there is a, non-trivial
number of people that have been working on this technology for years that
thinks that wallet data stations are just a really bad idea and are
anti-competitive. David, you're

David C: Yeah, I mean look, I've been working on this for 30 years and when
I started then cred, the credentials at the time were X59 certificates and
I had a Bill Gates certificate, right? And I used to give that to my
students and show look, I could sign messages saying I'm Bill Gates and
everything because there were no checks and balances on anything. The whole
thing was, very sign came along and just gave free certificates out to
anybody who could put anything in them. and then people realized we've
created a complete gargoyle here. This is just atrocious. And they started
to put rules in and they brought in the browser rules and more and more
trust. And so now we are in the situation where with a browser if you go to
a website and the certificate is not valid you'll be told that and the user
will be almost banned from going there.

David C: the user has to really work his way around to get to that website
that has an invalid certificate. So, the world has woken up to the fact
that you can't just allow a free-for-all because the bad guys out there
take advantage of it and academics like me take advantage of it to show how
stupid the system is if there's trust in it. So, I think that your
viewpoint is more akin to the 1990s viewpoint of X509, I would dare to say.
00:30:00

Manu Sporny: No I disagree. there is a difference between the software you
use and the entities you interact with in who No, I don't think anyone here
is arguing for a free-for-all. So, that's a complete mischaracterization of
the argument. there are issuers that certain people are going to, trust
more than others. and this spec that we're working on is very much about
that, right? so it's not a free-for-all. That's not what the argument is
more precise than that. It is about the software that somebody is allowed
to use in and in and how decisions are made around the software that you
use.

Manu Sporny: anytime you limit somebody's choice on the software that they
can use, it is an anti-competitive practice. If not in the beginning, it
will turn into one. That's not to say they're not legitimate other ways of
constraining the ecosystem, but this whole you have to have licensed
software to be even participate in the ecosystem for all use cases, is
totally misguided and even for things like education certificates is
probably misguided as well, right? so I think there's nuance here.

Manu Sporny: I think the community needs to tease that out because, it's,
folks that are saying, wallet data station is a bad idea are not arguing
for a complete free-for-all. we're identifying a pattern that has been used
repeatedly in anti-competitive behavior over the past 30 years. And we're
seeing the pattern again, and we're going, hey, same thing's happening
again. this time unfortunately it's being pushed forward by governments
which are probably not thinking through the anti-competitive issues that
are being created here. go ahead David.

David C: So I mean actually the main part of this text is the use case
which we haven't looked at. So maybe we can look at the use case first of
all and see what we think about the use case because the text is just there
to make sure the use case is supported because if I put the use case in
without all these changes to the text the use case wouldn't fit in. So
could we just change the conversation into looking at the use case Would
that be helpful?

Manu Sporny: Yes, I think I mean, I think what are we taking out of this? I
don't think we have consensus on this being a good idea. that said, the EU
seems to want to go down this path. And this is the terrible thing about
it. If we don't support it, They won't use the more open specs. It feels
like a Sophie's choice to me. go ahead, Dimmitri.

Dmitri Zagidulin: So I agree with your assessment. so the question is what
does we don't support it mean? We can just say since as David pointed out
you came to the consensus that a wallet at the station is a regular
verifiable credential. We don't need to do anything with the spec. We
already have issuers of verifiable credentials we don't need to do anything
special for W station to say that we support it.

Manu Sporny: I lift.

Dave Longley: Yeah, I think it's a mistake that's been made in the
ecosystem to think that any party can't be an issuer verifier.

Dave Longley: I think a lot of the mistakes that are being made by the EU
are based on previous two-party models and not really understanding the
three-party model and how there are different roles that any participant
can play at any time. It's fundamentally a different model from what some
of the other identity based software was doing in some decades ago. And we
should probably lean into that instead of saying we've got to call this out
and say it's a special case. It's not a special case and that's one of the
mistakes that's been made.

Dave Longley: this technology verifiable credentials and this issuers and
verifiers list all of these things are designed around generally making it
possible for anyone to make trust signals and then make their own decisions
about what to trust. So you put these things out into the world, you can
sign them to say this authentically came from me and then anyone can build
any systems they want to around that. And we don't need to go and give any
special preference or do any special work around particular use cases of
that technology that might lead to bad outcomes. but if questions come up
around it, we don't have to say no you can't do that.
00:35:00

Dave Longley: I would say you can do that the architecture supports it.
It's not special. You just identify who your issuer is in that case. if you
happen to call them in a creditor or wallets that's not relevant with
respect to the architecture. but I don't think we should go out of our way
to put things into the specification to even use cases into the
specification that are not that this group doesn't have consensus are good
uses of the technology. There are lots of other bad use cases we could put
in here. You can always use technology in bad ways and I don't want to say
sit here and come up with them, but I'm sure we could do it. and so I guess
that's my general feedback.

Dave Longley: I don't know how much value we get out of highlighting that
particular use case and putting it in this document, but I do know it
causes damage and it further proliferates the idea that wallet attestations
are different and that they're a good idea in the ecosystem.

Manu Sporny: Go ahead,

David C: I'm not saying that wallet assistations are different. So if
that's the impression the text gives, then I need to change it. I mean, we
already agreed earlier on in the discussion that they're just verifiable
credentials by an issuer and the recipient is a wallet software provider.
so looking at the use case, if you can put it on the screen, manual, it's a
bit higher up. Okay, there you David requests a driving license from his
national driving license authority. The DA interrogates David's wallet and
finds out that the software is not written by a trusted software supplier.
So, it refuses to issue the driving license to this wallet. I mean, that is
already I believe in the protocol for open ID connect.

David C: David then installs a certified EUID wallet on his device and
repeats the request. This time the dealer is able to obtain the not
attestation certificate issued to the wallet and it duly issues a driver
license to devis. so that's implying the technology is the same.

Manu Sporny: Yeah, I'm not hearing people saying that you are saying the
technology is different. I think we have consensus that this is just
another verifiable credential issued by a different type of issuer. I think
what's being said is putting this use case in here as a legitimate use case
does not seem to have consensus. I think some people think it's a bad idea
to even talk about the use case here and acknowledge it as a legitimate use
case. I mean if the EU wants this this can go into an EU spec right?

Manu Sporny: I mean, here's what I see kind of it kind of playing out,
David. even if we put it into this spec, it's going to go into the working
group and there's a subset of us in the working group that are probably
going to object to the language or even the concept of this is this being a
legitimate good use case. So, we would put text in here. I mean, we can,
put it as an we could if I'm trying to figure out if it's useful for us to
put the text in there with an issue marker around it saying that this is
contested and, viewed as a bad idea and yada.

Manu Sporny: and then we let it go to the working group where it will get
debated and discussed. Or if we're kind of like we already know the outcome
here, there are going to be a number of us that probably would formally
object to this and stop it here. I don't know. I can anybody else think of
a way forward with this?
00:40:00

Dmitri Zagidulin: I mean, that seems like a workable way forward. yes, it's
kicking the can down the road, but that's what work groups are for.

Manu Sporny: Okay, David, would that work for you if we just add an issue
marker in here saying that this is a contested use case and…

Manu Sporny: needs further discussion by the working group?

David C: Yeah, absolutely.

David C: Absolutely. Because as Thomas pointed out, this is going to be the
ISO use case.

Manu Sporny: Yeah, understood. ISIS, standards bodies are not,…

Manu Sporny: perfect. there are plenty of standards out there that are just
bad, yeah,…

Dave Longley: Do we want to highlight this as a closed ecosystem use case?

Manu Sporny: I mean I think Mhm.

Dave Longley: Let's use that language. so just right up front, if you want
to have a closed ecosystem, you can use the technology for that. So let's
call it a closed ecosystem use case and say there are some ecosystems that
limit the software that can be used to a specific set of wallets that have
passed certain certification and then do the rest of the text here. But
let's make that

David C: Yeah, I like that, Dave. Yeah. Yeah. Yeah. I like that.

Manu Sporny: David, do you want to make that update next week? after the
call and then just through issue marker.

David C: Yeah. Dave Longley,…

Manu Sporny: And then we can kind of work on Okay,…

David C: just bang a sentence in the chat now that you'd like to go in and…

Dave Longley: Okay.

David C: I'll cut the paste. Yeah. Thanks.

Manu Sporny: all right. that's this PR. we need more reviews on it. but
thank you David for raising it and triggering that good discussion. I think
it's time we started writing this stuff down as a group.

David C: There was just one technical correction that I made.

Manu Sporny: Okay. Mhm.

David C: And it was where I think in my opinion they got an entity wrong
and I changed the entity. So if we can just go down and find it in one of
their use cases they'd listed the wrong entity and I changed it. So if
someone could run their eyes over and think is it this one? where they'd
say Twin Mountain Hospital, I think they should have meant Acme, Inc. So,
this wasn't my use case. This is one that came from the rebooting the Weber
trust.

David C: So, anybody who was there, who remembers this use case can see
whether it's correct or not.

Manu Sporny: I am reading through it now.

Manu Sporny: Yeah, I think you're right, David. I think your change is
correct. I think there's something else that we probably need to do as a
group and that's to go through all these use cases.

Manu Sporny: These use cases are 6 years old now, I think. I mean, they've
been here for a very long time. whenever that rebooting web trust event
happened, is when these were generated. I expect that a number of them are
out of date or things that we may not want to support or things of that
nature. So, we might need a pass and a review on them. ideally I'd like to
just focus on some core use cases instead of just, listing a ton of them
out there. go ahead, David. Okay.

David C: Yeah, I did review them and they all seemed okay actually and they
still seemed current. yeah, so

Manu Sporny: All sounds It would be good to get some other eyes on it as
well. the other thing I'm concerned about is we have too many use cases
that are effectively duplicative of each other. right.

Manu Sporny: rather than pointing out reasons new data fields exist. it's
just variations of that use the same data fields. that's kind of what I was
trying to get at is if the use case doesn't establish any new data fields
that you need in the object then not we could probably remove the use case
and have no ill effect to the specification.
00:45:00

David C: Yeah, I think that is true.

Manu Sporny: Okay. All right. that's it for poll requests. Thank you, David
for raising that. I will try to raise, one and Dmitri, I think, we need
another one from you. we did discuss these. I think we've discussed all
three at this point, haven't we?

Manu Sporny: Dimmitri, do you know did your use case? No. If we did Yeah.

Dmitri Zagidulin: Apologies. Yes, I think we did discuss it in the sense
that this issue was open as a result of the discussion. I mean, if there's
more things to discuss, I'm absolutely happy to, but it's fairly bare bones.

Manu Sporny: Yeah. Fairly straightforward. and so the expectation is that
these are the properties that we would need in the data model to support
that use case.

Dmitri Zagidulin: Yeah.

Manu Sporny: And then these are the suggested properties for this use case.

Manu Sporny: And then David's got ones for his use case. Though David, I
think David your properties are just what's in the spec right now. Is that
I think that's correct.

David C: That's fine. Yeah. Yeah.

Manu Sporny: All right. So, once we get all the properties into the spec,
we just need to align. so maybe we can start that discussion a bit let's
see ro based clients usage of data model provide minimum I wonder if this
was the issue no maybe what we can do is just open up the spec and kind of
take a

Manu Sporny: go ahead, David.

David C: Yeah, that provide minimum viable example. the point I made I
think is worthy of us all discussing and is that a piece of software needs
a whole bunch of information and that information can either come from
configuration data or it can come from dynamic data that it gets given at
runtime. And the extreme of the former is that the only dynamic data you
get is And that unique ID sends you into a table that you configured with
and there you have your entire bunch of data that tells you how to operate.
And then the other extreme is you don't have any data hardly built any and
you get the whole thing dynamically and you make your computations based on
that.

David C: and your minimum variable was somewhere in the middle. that was my
assertion that it was neither a minimum because the minimum is just a
unique ID and it wasn't everything because everything's already in the data
model. So that's what I didn't like about your viable example. it was
neither minimum nor viable on its own. And it was only viable if you had a
lot of configuration information to go with it.

Manu Sporny: Got it. I think when I'm saying minimum viable, I'm talking
about things being self-contained, Meaning there is no external something
or another. you can execute the use case with just the information that you
received. There is no external anything that is configured. there may be
caveats to that. meaning your software might have the issuers at trusts or
a subset of them already in there. So I guess David what concrete change
are you requesting?

David C: I need to go back and read it now. Yeah. yeah.
00:50:00

Manu Sporny: You broke up on me, David.

David C: So yeah, I'm saying yes. this is my point where I was talking
about the two extremes. We got a unique ID or you've got the whole gamut of
information given to you. So I would need to go back now and look at your
technical solution to say why I think it's is in terms of a viable example.
Yeah, I didn't do that. This was a general comment I didn't go down to the
specifics. it's whether you agree with my general comment or…

Manu Sporny: Okay. Yeah,…

David C: not, I guess, as well is a point for debate.

Manu Sporny: let me try and kind of read through it. go ahead, Dmitri.

Dmitri Zagidulin: So my question is which use case can be satisfied with
just an ID? That to me seems insufficient at minimum.

Manu Sporny: potentially a verification use case where you really just need
to know the issuer ID these are all the issue IDs that I trust that could
be an example of one where it's like all you need is the thing that
generated the proof in the issuer and that can be just a single ID like it
did go ahead Dave

Dave Longley: I think even in that use case the reason why you would be
trusting that ID would be based on another list that had more information.
That other list would have been produced by some other party that had
information that allowed you to make the initial trust decision. So I think
you're still chasing it down. It's never going to be the case that if I
just handed you an ID, you were like, "Yeah, I trust that one." how would
that have ever happened? And so it feels like there's something deeper

Manu Sporny: Go ahead, And then we're out of time for today.

David C: No, I disagree with Dave. I mean, I could build a wallet that has
a set of IDs of trusted issuers and a set of IDs of trusted verifiers and
all the information that goes with them. And then if the user tries to
connect to an issuer the wallet it says, you just can't have a verifiable
credential because I don't know anything about him." and if he tries to
send a credential he's got in his wallet to a verifier, it says, " that
verifier is not in the trusted list, so you can't send your credit
credential to it." So, it's quite easy to build a system that works on
built-in IDs with all the information needs about them and then not to only
allow those IDs to go ahead or the wallet can say to the user, look, you're
now in uncharted territory. I can't help you at all.

David C: you have to do what you want because I don't trust the issuer and
I don't trust the verifier. and it's up to you mate.

Dave Longley: So I guess the difference here I guess that use case is the
information is out of band that initialized that list of ids that's the use
case that's being put forward I think.

David C: Correct.

Dave Longley: And so it's just a question of whether that's the baseline
use case. You have outbound information and then it came from somewhere.
You don't say anything about how that worked and then you have an ID and
that's the trusted ID maybe that's the simplest case. Maybe we want to
consider the case where you could chase all this information down to maybe
we should start with that as the absolute minimum use case. maybe it's
helpful to just start there at some point you have to connect to something
that's out of hand. So I think that's probably an okay place to say that
that is absolutely minimum. That's probably just not what we're going for
with these examples.

Manu Sporny: So potentially another use case where you get all your
information out of band and that's the minimum viable one and then what
we're doing is improving on that by allowing you to get the smallest amount
of information out of band and then you bootstrap from there. we are out of
time for today. thank you everyone for the great call as always. thank you
for the David in the good discussion on wallet data stations we will not
have a call next week because next week is the internet identity workshop.
we will move this call to Thursdays at 10:00 a.m. Eastern and our first
call back will be what was it October 30th.
00:55:00

Manu Sporny: until then, if you can raise, PRs on the spec, please do, so
we can have kind of concrete discussions around, some of this stuff.
appreciate everyone's time. have a great rest of your week, in, the next,
week and a half. See you all in two weeks. Take care. Bye.

David C: Bye.
Meeting ended after 00:55:34 👋

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