[MINUTES] CCG VCALM 2026-01-27

W3C Verifiable Credentials CG Call - January 27, 2026 - Meeting Summary

*Date:* January 27, 2026 *Time:* 14:58 EST
Topics Covered:

   - *Review of Pull Requests (PRs):*
      - PR for accepted_crypto_suites and accepted_envelopes in Query by
      Example (QBE).
      - Discussion around the authority field and its potential replacement
      with restrictions.
      - PR regarding the status section and its placement within the
      specification.
      - PR related to an interaction scheme for signaling interaction URLs
      and protocols.
   - *Issue Assignment and Prioritization:* A brief review of open issues.
   - *Open Discussion on VCOM Specification:*
      - Clarification of accepted_crypto_suites and accepted_envelopes in
      different query types (QBE vs. DID Authentication).
      - Implications of not specifying accepted_crypto_suites or envelopes
      in QBE.
      - Debate on using authority vs. restrictions for trusted issuers and
      other verifier-imposed conditions.
      - Exploration of nesting restrictions and the use of trust registries.
      - Discussion on the format of elements within accepted_crypto_suites
      and accepted_envelopes (strings vs. objects).
      - Clarification of the interaction scheme, its purpose, and its
      distinction from deep linking.

Key Points:

   - *Query by Example (QBE) and Presentation Requirements:*
      - The accepted_crypto_suites and accepted_envelopes fields in QBE are
      optional. If not specified, it implies acceptance of
presentations without
      a proof.
      - For DID Authentication queries, these fields are mandatory for
      specifying acceptable presentation proofs.
      - Clarification is needed in the spec regarding the interplay of
      these fields with the presence of a DID Authentication object.
   - *Trusted Issuers and Restrictions:*
      - The authority field (formerly trusted_issuer) is being considered
      for removal due to lack of implementation and potential for
      misinterpretation.
      - A restrictions field is proposed as a more flexible alternative,
      allowing for various conditions like trusted issuers,
verification methods,
      and credential schema IDs.
      - The concept of trusted issuer hierarchies and trust registries was
      discussed, suggesting the need for a model that supports recursive trust
      and delegation.
      - The PR will be updated to remove the authority field and create a
      separate issue to track the discussion on expressing trusted issuers and
      hierarchies.
   - *Accepted Crypto Suites and Envelopes Format:*
      - While current implementations might use strings for
      accepted_envelopes, there's a consensus to prefer objects with keys
      like crypto_suite and media_type for extensibility and
      future-proofing.
      - The spec should aim to support both formats for backward
      compatibility, recommending the object format.
   - *Interaction Scheme:*
      - The interaction scheme is intended for registering interaction URLs
      and protocols, with the intent to officially register it.
      - This mechanism allows native applications to register for URL
      schemes, enabling them to be invoked when a user clicks a link.
This is how
      VCI OID for VP and mdoc currently operate.
      - Distinction was made between this custom protocol scheme and
      HTTPS-based deep linking, with concerns raised about potential security
      implications and centralization due to relying on OS-level
scheme handlers.
      - The term "deep linking" itself is broad and can encompass both
      HTTPS universal links and custom protocol schemes.
   - *Other PRs:*
      - Work is ongoing on the status section, with discussions about its
      placement (appendix vs. spec section) and normative text.
      - A PR related to handling code snippets in the spec will be reviewed.

The meeting concluded with a plan to address the discussed PRs and issues
in subsequent meetings, with a focus on clarifying the specification and
ensuring backward compatibility where necessary.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2026-01-27.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2026-01-27.mp4
*CCG VCALM - 2026/01/27 14:58 EST - Transcript* *Attendees*

Benjamin Young, Dave Longley, Dmitri Zagidulin, Elaine Wooton, Eric Schuh,
Joe Andrieu, John's Notetaker, Kayode Ezike, Nate Otto, Parth Bhatt,
Patrick St-Louis, Susan Stroud, Ted Thibodeau Jr
*Transcript*

Patrick St-Louis: Welcome everyone. We'll get started in couple minutes.

Patrick St-Louis: Okay, let's get started with the meeting. So, welcome
everyone to the W3C credential community group VC call meeting for this
27th of January 2026. this is a 3C meeting. So W3C policies are into effect
for this call and all contributions discussed throughout the call. we have
a fairly straightforward agenda today. however before we get started I'd
like to give a moment for introduction or reintroduction. If anyone is new
to the call or would like to reintroduce themselves please do so now.

Patrick St-Louis: Very good. if there's any community updates, people would
like to share or any topics people would like to discuss and add to today's
agenda, please, raise your hand or put these into the chat and we will go
over that.

Patrick St-Louis: Very so for today, as mentioned, very straightforward
meeting. nice and easy start the day. so we will go over the review or
discuss the PRs. hopefully merge some of them. once this is done, we can go
through the issue assignment the issues try to do a little bit of
organization see what is priority and if there's still some time left after
that we can have open discussions about the VCOM specification.
00:05:00

Patrick St-Louis: so without further ado, I will go two of these poll
requests are mine. They've been open for a little bit over a month now. we
had some discussion about them. However, I've not gone back and address
those discussions. So I don't think there will be much purpose in going
over these two poll requests unless we feel the need to. However, there's a
new one about the accepted cristo suites and accepted envelopes. so this
has to do with verifiable presentation requests or presentation request
more specifically the query by example. So I would like to leave part to
explain to us what is this trying to address.

Patrick St-Louis: would you mind taking us through this?

Parth Bhatt: Thank you, Patrick. so this PR addresses the issue 542 and I
basically updated the index.html page. adding the accepted crypto suits as
an optional accepted envelopes as an optional in the query by example as
mentioned in the u comments or maybe the first comment from Dave Long only
and I have updated the query by example and then the verifiable
presentation request ML file as well.

Patrick St-Louis: very good. something I think I noticed about a point. So
accepted crypto suites. so this is for a query by example. So this refers
to the crypto suites about the proof that has been applied to the
credentials which are to be presented. However maybe someone can correct me
if I'm wrong in the case of a did exchange this relates to the accepted
crypto suites of the presentation itself. Is that correct? Yes, Dave.

Dave Longley: There is a separate query type called did authentication
which also takes the accepted cryptoes and accepted envelopes properties
and…

Dave Longley: so if you have a requested did authentication you can specify
the presentation accepted crypto suites and envelopes in that place. So we
reuse the same two properties they appear in the credential query for the
credential and if you are doing they did off query. Nothing.

Patrick St-Louis: So in the case that I have a presentation request and…

Patrick St-Louis: there's only a query by example, does this mean that the
prover does not need to attach a proof to its presentation.

Dave Longley: Yes, that is one way to interpret it. We probably want to say
in this spec, we probably want to be clear that if you don't list any
accepted crypto suites or envelopes, the expectation is that you would
accept no proof.

Patrick St-Louis: Wouldn't instead shouldn't instead it said that…

Dave Longley: And in the presentation there are use cases for that in vcom
certainly.

Patrick St-Louis: if there's no did exchange object in the presentation
request then you accept a presentation without a proof.

Dave Longley: Yeah, you're right. we should modulate that. So if there no
DID authentication request in the presentation exchange, that's what that
should mean. I think you and I Patrick had discussed how if you DID
authentication request into your VPR,

Dave Longley: you should be explicit about the DID methods, the crypto
suites, and any envelopes you would accept on the presentation. So if
that's how you're modulating my response, I agree. Yes.

Patrick St-Louis: Okay.

Patrick St-Louis: So if we have a verifiable presentation with a only query
by example, sort as it can be assumed that the verifier will accept a
presentation without a proof from the holder. if they have in addition to
the query by example did authentication.

Dave Longley: Data authentication.
00:10:00

Patrick St-Louis: So yeah, I get those two very mixed these days. did
authentication then there should be a proof and furthermore the data
authentication should also include the accepted fields whether that's
crypto suites envelopes and so on to be more specific about what their
software supports.

Dave Longley: Yes, I agree with

Patrick St-Louis: Okay very good. However seems to be like it's only about
the query by example. this distinction between this field based on the type
if it's not clear on the spec we should clarify it. I would have to review
the specification and be very specific that depending on the type of the
accepted cursuit and accepted envelopes are related to the different layer
of the proof which The other case is the credentials included in that
presentation. was very good.

Patrick St-Louis: I saw there was some discussion about authority trusted
issuers. I I wrote a reply. I didn't send it. I should have. I wanted to
raise the topic about so there's a field called trusted issuers that you
want to at least it was suggested to change it to trusted issuers. My
comment was so in the last few meetings we had discussion about predicates
and I did touch about this thing called restrictions. and having an array
of issuer that you trust could be considered as a restriction you want to
impose on the user.

Patrick St-Louis: I'm assuming if there's a list of trusted issuers, it
means the verifier will reject a presentation that's not issued by one of
these issuers. so I'm wondering if instead of putting trusted issuers as a
direct element, we want to implement another keyword such as restrictions.
And in that restriction, you could then list your issuers or there's
another use case which I mentioned instead of specifying an issuer that you
restrict on it could be a verification method. I think that could also be a
valid restriction.

Patrick St-Louis: so yeah my proposal topic of discussion is instead of
having either authority here we would instead have something like
restrictions which is an array and then in that you can have an object that
says issuer with the verification method with the string. These are
optional of course if they are included they need to be met or is trusted
issuer really something we want to include there and I see here it still
says authority so I haven't read what the rest of this was but yeah I'm
looking for Dave please share your thoughts

Patrick St-Louis: Yeah.

Dave Longley: right? …

Dave Longley: originally the VPR spec which got pulled into the VCOM spec
had a property called trusted issuer with the singular no s on the end of
it. I don't know how much implementation uptake that got. I don't think it
was a lot. and so when that spec was pulled into this one, I don't know
why, but I think that property was renamed authority. but the values were
kept the same. I don't think anyone has implemented that either. So, I
think we have room to make changes here if we want to make changes.

Dave Longley: Myself I could be amendable to putting this into a
restriction section, but I'll note that I kind of think accepted crypto
suites and accept that envelopes are themselves restrictions of some kind,…

Dave Longley: but those definitely have a lot of implementation support. So
we can be flexible here and figure out what we want to do if we want to. I
know the spec today got this authority field in there. I do want us to
remove that sooner rather than later. I don't think anyone's implemented
that and I think it sends the wrong message about how VCs work.

Patrick St-Louis: Yeah, I have a feeling this come from DAW.

Dave Longley: So, I definitely want us to

Patrick St-Louis: I know in the DAW there is some kind of authority field
that is issuers. So my gut feeling is it could come from there…

Patrick St-Louis: which Nate seems to approve in the message. yeah.
00:15:00

Dave Longley: Yeah, I think we should get that change right away…

Dave Longley: because this is similar to the kind of language that came up
in the trusted VC issuers and verifiers calls where is the idea of
mirroring centralized stuff from the past where there are authorities for
things rather than anyone can issue say anything about anything which is a
fundamental principle of VC. sees we should try to make sure our language
reflects that.

Dave Longley: And so I don't want to lose the fact that we're looking to
have a feature in here to be able to specify which issues would be trusted
by a particular verifier. I also don't want to keep authority in the spec,
but I'm also amendable to maybe having a nesting under restrictions and
modeling it differently. So those are my general concerns and now we'll get
off the queue.

Patrick St-Louis: Yeah. Yeah.

Patrick St-Louis: Ju just last note and then I'll let you take the mic Nate
my so with restrictions the only thing that would need to be reflected on
is the logical operation of these different restrictions right so if we
have different issuers verification method the sort of the end of these
things like how would a wallet sort of essentially filter their credentials
to see what fits

Patrick St-Louis: this need. And then another thing I could see fit in
there is a credential schema ID, That could also be anything that is of
whether it's the ones I can think is an issuer verification method schema
ID URL could be JSON schema right or anything or so on. So they not sure if
context would fit in there. I think that's fine for query by example but
maybe a verifier could be I accept these different contexts for that
credential but probably somewhere more first and Jason LD can tell me if
that makes sense or not. Nate

Nate Otto: Thanks. I'm not super particular about the language used here,
but I just wanted to bring up that there are a bunch of use cases where the
issuers that will be accepted are not explicitly known. that they maybe are
any issuer registered with one of these five issuer registries or trusted
issuers at verifiers lists that I trust. And it's not only going to be as
simple as setting here are the three trusted issuer identifiers that I
would accept a credential from. It's like the oid for VP spec says is here
are some frameworks or registries what they call authorities that I trust
to decide for me whether a certain issuer is acceptable or not.

Nate Otto: in this space will see a lot of growth and development soon. So
as long as we don't paint ourselves into a corner here with how we are
specifying what may not be trusted that would be good.

Patrick St-Louis: Yeah, that's interesting.

Patrick St-Louis: There's definitely two approach where there could be the
approach that the verifier doesn't specify that and the verifiable
presentation request but kind of then refuse the presentation with that
reason sorry I don't trust that this is not someone that I trust. the other
way is they advance like they know a network of issuers or it really
depends on the use case.

Patrick St-Louis: I don't have a tangible use case I've seen where it lists
a trust registry I feel that space is there's very different ways to do the
closest thing I've seen was the dcc sort of issuer registry list may not
still be used. that was interesting. but even then I've not seen that used
in a verifiable presentation request. I think from what you've said going
the way of putting a field called restrictions which leaves the room later
on to implement some kind of way to restrict on a trust registry or so
would be preferable than defining a term right now that we use right at the
root here like putting trusted issuer.

Patrick St-Louis: maybe we do want to put trusted issuer because we know
issuers will be there but maybe having something like restrictions or I
keep saying restrictions because that's just the term we use with anon
grids and it kind of ex explicitly explains what this field would be for
Dave
00:20:00

Dave Longley: So, I want to talk about two things. the first I'll be
responsive to the current thing that Nate just said. In the original VPR
spec, we carved out a section for talking about trusted issuers. And we
meant for that field to be recursive so that you could say that a trusted
issuer is itself trusted by another issuer that the trusted issuer must
present a VC of a certain type. I think there's more work to do there to be
really clear and explicit about how to do this and some of this work folds
in with what is happening with the trusted issuer and verifiers work. But I
do think we need to have two things going forward.

Dave Longley: The first thing is obviously we need to have the error case
where something's presented and we already do I believe we have the error
case where something was presented that's not trusted or…

Patrick St-Louis: Mhm.

Dave Longley: acceptable to the verifier that should always be there as a
catchall but we also want to be able to announce in the VPR I would accept
either these explicit issuers or I would accept an issuer that has a VC
that is issued by this other party and then there might actually be a chain
involved in that. So I'll take anyone that is it an accredited university
for example and you might end up presenting as an end user from the issuer
that gave that to you and then another credential and accreditation
credential for that intermediate one.

Dave Longley: So I think there's a lot of use cases there and we want to
make sure that the model that we build will support being able to sort of
go up that chain and…

Dave Longley: have verifiers announce I would accept these direct ones or
this other kinds of metadata information and if anybody's following some of
the people in this group are part of that recognized issuer data modeling
stuff we're doing I think we could mix some of that in here. yes. Yes.

Patrick St-Louis: and interesting.

Patrick St-Louis: So it' be sort of saying you can send me a credential but
you also need to send me some kind of credential that attest to who the
issuer is some kind of credential about the issuer. yeah, that's
interesting.

Dave Longley: And you can say what kind of credential that is and…

Patrick St-Louis: And do we feel like putting that in the query by example
is starting to be quite a lot to put in there?

Dave Longley: we might have a standard one coming out of that other group
that would allow for this to be a sort of much simpler way to do it. I
don't know that you would pull it all the way to the top level of the query.

Patrick St-Louis: Wouldn't that be a different kind of query like trusted
issuer query or I don't know query by Yeah.

Dave Longley: we can discuss all those details. but I want to make I guess
two more points. The one was about the We have some top level andor logic
for grouping things today and…

Dave Longley: I think if we can just leverage and reuse that even if it
makes your queries more verbose I think it would be a simpler thing for
people to code to.

Patrick St-Louis: Yeah. Yeah.

Dave Longley: So there's just one place if you have different sets of
things you can accept put it in another group and at the end of the day you
make one selection from one of the available groups in the presentation as
the user. and I think that way every subpropy just lists here are all the
things I'm willing to accept and you don't have any other more complex
logic there. and then if I can remember the final third point I wanted to
make. I don't know that I can though. I was going to propose that in this
PR since we still want to talk about this authority property. I was going
to suggest in this PR that we remove from the example where we have
authority today.

Dave Longley: We remove it but we leave an issue that says the group is
currently discussing how to express trusted issuers and hierarchy of
trusted issuers and just leave it as an issue in the spec so that we can
get this PR in and then have further discussions on how exactly we want to
model all that.

Patrick St-Louis: Yeah, I think I like that approach of tackling this
discussion in something else instead of just leaving this R open for quite
some time. these queries, they don't They're just an object like they don't
have a ID field with the U ID or…

Patrick St-Louis: something that could be referred in a subsequent query.

Dave Longley: We haven't specked that out and…

Dave Longley: haven't found that we need to. but we could add that…
00:25:00

Patrick St-Louis: I was thinking just…

Dave Longley: if we find that it makes sense, but I do know that that can
get pretty complex pretty quick.

Patrick St-Louis: what I said if there is a separate query right that means
prove this issuer and then you can refer the ID of which query by example
it talks about so when you're going to present me this credential for this
query by example By the way, here's another query for another credential
that needs to support that issuer. I don't know if it matters, but if we
have one query by example, then they would need to send two credential
right to meet in the presentation to meet this one query.

Patrick St-Louis: I don't know if it was kind of intended that each element
of this array is equal to one credential in the presentation or if that
doesn't really matter. probably it does not really matter. yes, Nate

Nate Otto: Just a couple things really quick. if we use a very generic term
like restrictions, that is a very broad thing and so maybe we would have
something that is about issuer restrictions within that. I just wanted to
speak for the idea that there is some value in having a section of this
that is specific to the idea of which issuers authorities that we might
accept for this particular query separate from things like crypto suite
restrictions and other sort of more technical restrictions.

Nate Otto: also plus one to the idea of separating out the conversation
about what should we do for that to not block this poll request. And then
to also note that Dave mentioned these sort of trust chains like I would
trust an issuer if they hold a certain credential from a certain issuer
that I trust.

Patrick St-Louis: Yeah. Yeah,…

Nate Otto: that is very similar to something that is in production more in
the JWT X509 Jot header world where you can put some and so Europe is doing
some work on implementation using some systems like that and doing it with
VCs is an interesting idea as

Patrick St-Louis: it's not a bad idea. We could have more accepted issuers,
accepted verification method, accepted schema.

Patrick St-Louis: this route could be also used instead of having this
restrictions field that then list these and it would look kind of good I
think this could be discussed in this other issue so that's one thing would
you be okay with this to update this remove authority and add a list add

Patrick St-Louis: an issue about this accepted issuers condition and maybe
leave a note in there that other accepted fields might be considered in the
future such as and I say verification method and schema because these are
use case that I will likely need and it would be very convenient to express
them. one thing that this would make it kind of difficult is if you have a
bunch of arrays here, you have one array for your crypto suite, one array
for your envelope, one array for this. you cannot group some together like
you couldn't say I want this issuer and this schema, right?

Patrick St-Louis: Or I suppose you could and…

Dave Longley: Yeah. So that's the grouping feature does that today. So you
can do exactly that. It just happens at a high level. So there's a Yeah.

Patrick St-Louis: Yeah, you would need another query by example. pretty
good. Yeah. Okay.

Dave Longley: And so I think we've got that covered. And I really like your
proposal for accepted issuers because it fits in with what we're already
doing. And then having accepted, XYZ for anything else makes sense. And the
individual values in those arrays can be…

Dave Longley: then be really specific for the type of restriction.

Patrick St-Louis: Yeah. And…

Patrick St-Louis: then regarding the thing about trust registries and so
I'm sure we could figure out how to express that also with this model.
might not be accepted issuer but might be accepted delegation. I don't know
something. Yes Dave.

Dave Longley: But I was thinking that in the issuer value, you might not
name an issuer. you might say anyone from this list or…
00:30:00

Dave Longley: anyone who has a credential of this type from this other
accepted issuer. so I was thinking it could be nested like that, but we can
figure that out later. I did want to note that one of the things that I
think we need to figure out on this PR is another comment. so I'll talk
about that next. I see Joe's on the queue. He might want to talk about
whatever we just said. but I'll put myself back on the queue to talk about

Patrick St-Louis: Okay, Let us know…

Patrick St-Louis: what you're thinking.

Joe Andrieu: Okay, sure.

Joe Andrieu: Mine was a short note. I'm not sure it needed to interrupt
you, Dave, but confidence method is also going to be something we're going
to probably want to have as a restriction, but I don't know where we get
that. but it was triggered by your comment about wanting verification
method…

Patrick St-Louis: Okay. Yeah.

Joe Andrieu: which is we are using confidence method to say hey this
verification method is a confidence method for a subject of a VC and I
could see a relying party saying hey I want a credential that has a
particular kind of confidence method.

Patrick St-Louis: The reason I mentioned verification method is very
simple. It's because in the crypto suite meaning the alon creds in vcdm 2.0
format the verification method represent something called a credential
definition ID and that's a very key component to use at the restriction. So
there the reason I wanted to have at least a mechanism to put a string
which is a verification method ID because I have a very pragmatic use case
for how that relates to confidence method yeah I mean I'd be very happy to
see…

Patrick St-Louis: what can be done with this. are you saying that having
this accepted verification method would somehow prevent this from happening?

Joe Andrieu: No, no.

Joe Andrieu: I was just saying there's also this point of extensibility
about the confidence method and…

Patrick St-Louis: Okay, awesome.

Joe Andrieu: so I was just really socializing this is something we are
eventually going to want to fold in. I'm not sure we need to change what
you're doing here.

Patrick St-Louis: I think just starting with the issuer will be a good
place to start. very good. Dave, you mentioned there was another issue.

Patrick St-Louis: We can still go through some of the other comments here.
definitely Okay.

Dave Longley: And this is related to those other comments,…

Dave Longley: but I did want to plus one that we could have accepted
confidence methods on there as well. that would make sense. one of when I
filed the issue related to this PR that the PR is going to close, I think I
handcrafted some query by examples with accepted crypto suites. And I later
found that some implementations, maybe all of them, I'm not sure. use an
object field, not just a string, and they list the crypto suite name. And I
think that was done for extensibility purposes if there would be any other
sort of constraints that you might need to put in those objects in the
future. and so in the comments I recommended that that's what we spec out
though we might want to accept either …

Dave Longley: since we're not entirely sure what people have implemented.

Dave Longley: we might want to accept either or we might want to accept
either just to give people a simpler version if they don't have other
constraints. So that this is about what do the elements in the accepted
crypto suites array look like? Are they just rings? are they objects with
for now the key crypto suite with the string value in there? Certainly, I
think we need to support that one because that's in the wild. and then go
ahead. Yes. Yes. Yes.

Patrick St-Louis: Yeah. is your concern that some crypto suite could have
some other element on the proof that would go with the cryptosweet string
and…

Patrick St-Louis: you want to this crypto suite with this other thing which
doesn't exist now but might exist in the future. okay yeah I think that's
reasonable. I think that the same thing was in this authority or trusted
issuer and then there was a list of object with the issuer key. and this
was one of the reason why I had suggested restrictions because you kind of
just have restrictions which is your array and then in that you have issuer
and so on. But actually that goes against what we kind of just discussed.

Patrick St-Louis: it does make for a larger presentation request which
might be okay might be not and also more often than not I think that when
people will say accepted crypto suites it will likely because they support
a few I think it's very rare that they will just list 10 crypto suites I
think if people want to restrict they will it's because their software
00:35:00

Patrick St-Louis: where they're looking for specific thing realistically.
probably one selective disclosure enabled crypto suite and…

Patrick St-Louis: one I have some concern and maybe that's just a
non-issue, but this one it's a type, It's not a crypto suite like the
ED25519 signature 2020, but we can probably sleep at ease even with that.
being a thing. Joe, wait.

Joe Andrieu: Yeah, I just want to suggest that I think the pattern I'm
seeing is that there will be lots of crypto suites supported…

Joe Andrieu: because we're building these sort of middleware platforms that
are trying to on some level be like Adobe Photoshop and Adobe Photoshop
doesn't care what your image format is. They want to be able to work with
it. So they can ingest a PNG, a TIFF, JPEG, whatever. And so I do expect
that a lot of at that layer there will be dozens or more of crypto space
that the platform could accept.

Patrick St-Louis: interesting. Okay,…

Joe Andrieu: So just I mean I think that's the win.

Patrick St-Louis: I say that without much implementation experience with
this. So I think what you just said is probably more reflective of the
reality.

Joe Andrieu: I think I want a platform that lets me do all this stuff. So
if someone had a platform that could do it all,…

Patrick St-Louis: Yeah.

Joe Andrieu: they'll get my $20 a month or…

Patrick St-Louis: Yeah. Yes.

Joe Andrieu: whatever their license is.

Patrick St-Louis: Yeah. Yeah. I guess I'm coming from the space that the
verifier might be very specific in what they're looking for. and the more
things that are in there the more difficult it will be for the wallet to
implement because these are there for the wallet right they're not really
there for the verifier is there for the wallet and I'm just curious what
the logic would look like to select the crypto because it's not going to
ask the user which crypto

Patrick St-Louis: suite you want to present, that's not what's going to
happen is the wallet will need to be able to select this.

Patrick St-Louis: And I'm just curious. That's an implementation detail,…

Dave Longley: I can speak to that.

Patrick St-Louis: but I'm curious how that selection could happen.

Dave Longley: So I can speak to that. first I think having a larger list.
So actually first I will say that VCOM is designed so that the exchanges in
VPR doesn't matter whether the response is coming from a wallet or…

Dave Longley: some other party. it's not Yeah.

Patrick St-Louis: A holder.

Patrick St-Louis: A holder like Yeah.

Dave Longley: Yeah, that's true. The holder. I just wanted to be clear that
the design is that way so that we don't get sort of painted into corners
around putting the roles where they don't need to be restrictions. but it
is certainly going to be a holder of the credential because they're being
asked to present something.

Dave Longley: I think the size of these lists are going to widely vary but
I think a larger list is actually more helpful for the holder than anyone…

Patrick St-Louis: H. Yeah. right?

Dave Longley: because it means more things are accepted. So whatever the
holder happens to have that if there's a larger list of acceptance they're
more likely to be able to present. As for making the selection, just
quickly as for making the selection, I think when this is surfaced to
users, what users are more interested in is what information is going to be
presented. how linkable am I going to be in my presentation? what the
privacy level is. and maybe whether or not the level of security with
respect to how far into the future the data is going to be protected and or
may not matter based on what the crypto suite is.

Dave Longley: But I think those are the sorts of things the users would
care about more and they're probably going to have some defaults like I'm
gonna choose digital wallet provider X because they give me these really
good privacy pro properties for example I'm expecting them to handle that
stuff for me and…

Dave Longley: surface what I want to know on the screen. They're not going
to care whether it says EDDDSA or ECDSA with other letters and…

Patrick St-Louis: No. Yeah.

Dave Longley: years. and I know that's how people have been designing
wallet interfaces to date.

Patrick St-Louis: It could be instead of selecting a crypto suite, do you
want to share the more private version versus the more explicit version,
like that kind of language? which it should probably always just send the
least explicit one,…
00:40:00

Patrick St-Louis: but that's probably not the language I could see it being
used.

Dave Longley: Yeah. For Yeah.

Dave Longley: For digital wallets that are for individuals that are looking
to protect them and do data minimization, they're going to have defaults to
choose the most privacy protecting crypto suite that is on offer.

Patrick St-Louis: That's cool.

Dave Longley: And if something is not there that's on offer, the wallet's
going to try and do a good job of surfacing, hey, if you present this,
here's the information you're presenting. And by the way, you might be
linked in these ways with the option to click and…

Dave Longley: dig for a user to click and dig in and try to understand what
it means to present the information.

Patrick St-Louis: Yeah, super.

Patrick St-Louis: Okay. so I feel like, besides this one with the string
versus the object, I think we seem to be on this all on the same page. that
we want objects with the cryptosweet key instead of just strings in the
array. there was mentioned that we might want to accept one or the other.
here it was added in the example the word cryptosweet. Do we want to make
the decision today that it needs to be an object with crypto sweet?

Dave Longley: So here's some more information. what is implemented in the
wild for accepted envelopes just What is implemented in the wild for
accepted crypto suites uses objects. And that I never like inconsistencies
like that. So we might want to allow both for both. That is Another way
forward is crypto suites use objects for accepted crypto suites and
accepted both for envelopes because I'm guessing that the object pattern is
better. It's more extensible and allows for us to improve things in the
future.

Dave Longley: So really I think the fact that people have implemented
strings for envelopes today it's really important I think for VCOM to make
sure that we don't break existing implementations going forward. So I think
we should spec anything out that even if it's deprecated. so I think we
need to support both for accepted envelopes but I think we should also for
accepted envelopes allow an object where you say media type…

Patrick St-Louis: Mhm. media type.

Dave Longley: because that's the media type that's in there.

Patrick St-Louis: Are these change we want to put on this PR before we
accept talking mostly for the media type here. it sounds like we want to
recommend the use of objects. However, strings are also supported not as
preferred.

Dave Longley: I would support that.

Patrick St-Louis: It may be a note saying we would rather have media type.
so this was commented one hour ago. I feel like this might be worthwhile to
add in this little bit of information. Perfect. I see part gave a thumbs
up. So I'm going to summarize this. So as on trusted fake accepted issuer
will be discussed separate issue.

Patrick St-Louis: it would be for useful to recommend using We also support
strings.

Patrick St-Louis: pending change include adding media key or set envelopes
objects. I don't know if this is super clear. I'm trying to summarize a
little bit what we just discussed with a fairly simple actionable thing.
00:45:00

Patrick St-Louis: and put a note to mention strings are also accepted but I
don't know if we want to say they're not recommended but maybe just word it
nicely to nudge in the direction of preferring an object without explicitly
saying it's bad. just so that people that do that currently don't feel too
put to the side. and it seems to me like the accepted envelope is the only
one that was missing this. so just make sure you review the current
examples.

Patrick St-Louis: I'm going to commend this and I'll let you go through the
suggestions that have been Perfect. was there any further comments on
before we move on to any other notes that can be added otherwise?

Patrick St-Louis: so for the two other PRs mentioned this one was about
adding a section for the status. I initially had in the spec section about
status. It was discussed to put it as an appendix and then it was discussed
to actually not do it as an appendix and put it back into the spec but with
less normative text. So that's still what I'm working on. I can see here I
remember Dave you had mentioned just the path that you use in your
implementation. I have problem with that to use a status list instead of
credentials status status list. So I'll implement this and then I will just
move this content into the status section of the spec most likely. I'll see
where it's at now.

Patrick St-Louis: I think there's a small section either there's a status
service or the issuer and try to make sure that the text still makes sense
in that new place. I don't have more comments to that. so this was a bit of
a messy one because we wanted to include but we don't really have code
snippets currently in the specs. So there was a broader section about how
respect handle code snippets but I don't think this is part of this. so
yeah I'll just have to review this review the work that was done here. I
link the issue the issue is still open. So this is on me to go to what was
discussed. this is also relating to query by example.

Patrick St-Louis: So I'll make sure to think about what we've discussed in
case it affects any of this. So what we just discussed about
nonrestrictions restrictions accepted things that represent restrictions.
very good. So I see there's couple minutes left. We can maybe glance over
the issues. we only have 24 issues. That is not that much. and a few of
them they have PRs open. okay, let's review this one. So, two weeks ago, a
PR was added for an interaction scheme to signal that, this is an
interaction URL and it offers a list of protocols.

Patrick St-Louis: we had discussed that we might officially register this
and I think this comment by Ezekiel is something that I was also thinking
after that is that interaction is a very generic term. I do not know every
single scheme out there. However, the ones that I do know they're not
dictionary names, right? They're not dictionary words. They are very
specific, HTTP but they're often acronyms so this is what I would like to
question whether interaction is too generic as a thing especially if we go
the route of not officially registering it. Is there a chance that
interaction can be used for something else? I've not read this response yet.
00:50:00

Patrick St-Louis: I should probably I understand why we don't want to use
VC API or VCOM as the scheme because I can call it a sort of a exchange
protocol of some sort at least the way it's used in the protocols do the
interaction make sense there c Yeah, I think if we go the route of
officially registering it, I would lean more towards supporting it. But if
the idea is just like it's only going to be in the spec and…

Patrick St-Louis: people need to know, I would caution maybe or suggest to
have some conversation around this. yes, Dave. Okay.

Dave Longley: So I think we definitely intend to register it,…

Dave Longley: put it in the registry and I put a link to the registry so
people can see what's in there today. Interaction is not in there. There
are a number that just use regular names, attachment, reload, hack, things
like that. one over all the years has ever grabbed interaction. it matches
what we want to do. And as I put in this comment,…

Dave Longley: the scheme is meant to represent the functionality of what
the thing Where it lives, what spec it's in is what link you put in the
registry. So, yep.

Patrick St-Louis: get more information.

Patrick St-Louis: Okay.

Dave Longley: And so, I think we're following that process. And so it makes
sense to

Patrick St-Louis: I'd like to if we can have qu there's not much time left.
So I would like to ask some question about this interaction protocol to get
an idea of where it could be so something that were shared before was that
not as a QR code. It's to be used on a website when a user will click in a
browser on something to trigger specific things. my question is what will
make the browser interact a special way with this? Wouldn't that require
specific feature to know what interaction is in order for it to trigger
something?

Patrick St-Louis: if I want to use this tomorrow, how does this benefit me
or is this more in a long-term sort of hope? so I'm curious to have some
thoughts around that. Yeah, Dave.

Dave Longley: So today operating systems allow native applications to
install and register for URL schemes so that if any link is opened in the
application that will open that scheme will be invoked.

Patrick St-Louis: All right. Right.

Dave Longley: This is how VCI oid forvp and mdoc do things today. they
create a link and a native application that's able to handle that link
registers to handle that scheme handler or that URL scheme and then it will
be invoked or offered as a choice in a selector if you're using an
operating system that supports that.

Dave Longley: So for example if you're using Android you'll get a chooser
application if you click on this. I think today someone can correct me if
this is wrong. I think today on iOS if more than one application registers
for something I think it doesn't work. I think you get a silent failure
which is sad. and maybe Nate's going to speak to that. maybe that's
improved.

Dave Longley: But that Patrick that's how it works. Okay.

Nate Otto: Yeah, I can jump in real quick and…

Nate Otto: which is that one of the apps will open that has registered it
and Apple's documentation is unclear about what it was. In reality, it
might be the most recently installed app that has registered for that
scheme. But it doesn't fail silently at least.

Dave Longley: Okay.

Patrick St-Louis: So I remember…

Patrick St-Louis: what you just said right on Nate I remember it's been a
topic of conversation at some of the IW this is definitely a conversation
that's been approached in the concept of deep linking. How is this
different than deep linking? Because we had discussed before deep linking
in this call and it was deemed as a very bad thing and…

Patrick St-Louis: rejected. but this seems like it's the same thing of what
you just explained.

Dave Longley: So it is not Yeah.

Dave Longley: So it's not the same thing as Deep linking is different
because a deep link is an HTTPS URL to a specific application where if you
are in control of the domain for that HTTP origin that's in that URL, you
can publish a file at that domain that authorizes certain native
applications that have been installed to be invoked. but it's all very
specific for example a particular wallet.
00:55:00

Dave Longley: So the link would be you can imagine a NASCAR style page if
people are familiar with that terminology for login where it's login with
these 10 different providers on the page and that each one getting its own
special link and that has been a problem in the identity space for a long
time. why things like the credential handler API that and the Chappie
polyfill were invented to eliminate those NASCAR screens because they
ultimately result in centralization of the handler space because people end
up having to write special code work with only special choices by the users
and you end up having two or three of these things on the screen.

Dave Longley: It leads to centralization of big providers for things. And
so that is the disadvantage of the deep linking approach. But the deep
linking approach has the advantage of being a more secure experience
because which application there's a better security profile around which
application is going to launch if you click that link. it doesn't have this
sort of any application that you pull off any store can install and install
itself to handle a URL scheme which is not a great security practice.

Dave Longley: and we were hoping to completely avoid this with the advent
of the DC API at W3C, but there have been a number of hiccups and bumps
along the way with that API. And it's starting to look as though we don't
know. You never really know, but it's starting to look as though Apple
might only support one specific format and one specific type of credential
with the use of that API, which doesn't work for all of the other types of
credentials and use cases out there.

Patrick St-Louis: Because I'm just reading now deep link.

Patrick St-Louis: So there's deep link and there's deep linking. and here
it seems like mobile deep linking is more similar to this interaction model
here. as normal deep linking is closer to what you explained earlier that
you have a HTTPS URL with that points to a specific resource. but it seems
at least according to what I'm reading on a Wikipedia here mobile deep
linking does in fact refer to having a scheme and this triggering a mobile
app to open.

Patrick St-Louis: Yes, Demetri. Okay.

Dmitri Zagidulin: I just wanted to echo what I said in chat and what you're
saying right now with Wikipedia deep linking is a broad term that refers to
both universal app links that are HTTPS and custom protocol. So just we
should be clear in our terminology.

Patrick St-Louis: And this is just something that I just learned. I didn't
know there was a difference. And it seems like because when I was thinking
about deep link and when I've discussed deep link in the context of digital
identity it was most often with this my mobile is going to open an app
right I'm going to have this scheme and didcom for example I have a com
semicolon slash and then it's going to either open in the case of Apple
it's going to in a random app or not random whatever in the case of Android
is going to give me a choice of here's the app that supports this when I
talk about deep linking that's what I had in mind and this seems to be
exactly what's happening here is that

Patrick St-Louis: Right. Yeah.

Dave Longley: I was putting this in chat. I think the language here is
pretty fluid and understood differently across different providers. What
you just described as what this would do I think is accurate. So this is
for same device. If you put the link somewhere, you click it, it's supposed
to open an application and it will be whatever application that the user
has either installed most recently is what it sounds like maybe on iOS or…

Dave Longley: it will be if there are multiple applications available a
chooser on Android and what other systems do on desktop and so on is up to
those platforms and…

Patrick St-Louis: Okay, very good. okay.

Dave Longley: none of this is good but it is the only way on a same device
today to get that kind of invocation without having spe a special
integration or special knowledge about which applications you might open
which is the other kind of deep/universal applink approach.
01:00:00

Patrick St-Louis: I say in very good. I understand not as an opinion
whether that's a good thing or not. I'll abstain from that opinion. I don't
feel like I understand all the risk and everything quite yet to have a
strong but I do understand your point about it maybe not being good. this
being said it's one past the hour. this will conclude the meeting today. So
we made some pretty good discussion progress a lot of focus around the
presentation request which is key.

Patrick St-Louis: no presentation requests. can't do much with those
credentials. so that's been really good. so we'll see again each other
again next week. we should be able to at least close two PRs and I'll try
to see if I can open a new one for something. so thank you very much
everyone for Have a good rest of your day. And on that note, I will join
the meeting.
Meeting ended after 01:01:24 👋

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