[MINUTES] CCG Incubation and Promotion 2025-05-28

CCG Incubation and Promotion - Meeting Summary (May 28, 2025) Topics
Covered:

   -

   *Confidence Method Specification Updates:* The group reviewed updates to
   the confidence method specification, including modernized references, added
   definitions (conforming document and processor), and updated status to
   "experimental." Discussion centered around potentially renaming it to
   "authentication" and aligning it with authentication mechanisms in DID and
   CID documents. The implications for verification method properties (id
   and controller) were debated, with a conclusion to allow referencing
   verification methods without embedding full contents. The inclusion of a
   biometric portrait image example was discussed, acknowledging privacy
   concerns but advocating for its retention to stimulate broader discussion
   within the VCWG on privacy-preserving biometric mechanisms. The use of DIDs
   for increased confidence was also explored.
   -

   *VC Barcodes Specification Pull Request:* A pull request adding
   algorithms for encoding verifiable credentials as QR codes was reviewed.
   This addresses a missing base use case and includes an example using a
   birth certificate to combat fraud. The use of C4LD for binary compression
   was highlighted, demonstrating significant size reduction.
   -

   *Community Updates:* Seven verifiable credential specifications achieved
   global standard status. The group discussed the continued incubation of
   other specifications, with some automatically transitioning to the VCWG and
   others requiring a VCWG re-chartering.

Key Points:

   - The confidence method specification may be renamed "authentication" to
   leverage existing DID/CID authentication mechanisms. This requires further
   discussion in the VCWG.
   - The inclusion of biometric examples in the specification will
   facilitate a discussion on privacy-preserving biometric practices within
   the VCWG.
   - A new pull request significantly enhances the VC barcodes
   specification by adding QR code encoding/decoding algorithms, improving its
   practical usability. C4LD compression is integral to this enhancement.
   - Several verifiable credential specifications have reached global
   standard status, signifying significant progress in the field. The group
   will continue incubating and finalizing remaining specifications.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-and-promotion-2025-05-28.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-and-promotion-2025-05-28.mp4
📝 Notes

May 28, 2025
CCG Incubation and Promotion

Invited W3C CCG Meetings <meetings@w3c-ccg.org> ~~msporny@digitalbazaar.com
~~

Attachments CCG Incubation and Promotion
<https://www.google.com/calendar/event?eid=MnRvb2JxZ3V2NzVzaHA3NnJpbGtmMm41bmhfMjAyNTA1MjhUMTUwMDAwWiBtZWV0aW5nc0B3M2MtY2NnLm9yZw>
CCG
Incubation and Promotion - 2025/03/26 10:58 EDT - Transcript
<https://docs.google.com/document/d/1YZd-ltG16RCSWESz-3zdiaxbwnaKDReuCfp1CigoQ9Y/edit?usp=drive_web>
CCG
Incubation and Promotion - 2025/03/26 10:58 EDT - Recording
<https://drive.google.com/file/d/1FLd0qC-x_mVoSaQ0FFuJYS5yvV15K6CL/view?usp=drive_web>
CCG
Incubation and Promotion - 2025/03/26 10:58 EDT - Chat
<https://drive.google.com/file/d/1JfWAi3j1RJ07NzlK-BhsDVpkRA2NKsH7/view?usp=drive_web>

Meeting records Transcript <?tab=t.1z6wk6rjen0f> Recording
<https://drive.google.com/file/d/1wQo-92xbAfq6CGHzVTM6hYVxLddZTSKw/view?usp=drive_web>
Summary

Manu Sporny led the Credentials Community Group meeting, covering updates
to the confidence method specification, including modernizing references
and adding definitions, and discussed its potential renaming to
authentication. Dave Longley contributed to the discussion on aligning the
confidence method with authentication mechanisms in DID and CID documents
and the implications for verification method properties. The group also
reviewed a pull request for the VC barcodes specification, which adds
algorithms for encoding verifiable credentials as QR codes, and Manu Sporny
provided community updates on related specifications.
Details

   -

   *Welcome and Agenda* Manu Sporny welcomed everyone to the Credentials
   Community Group incubation and promotion call for May 28th, 2025. The
   agenda included discussing the confidence method specification, a pull
   request for the VC barcode specification, community updates, and any other
   progress (00:00:00 <#00:00:00>).
   -

   *Introductions* Vicas Malhotra introduced themself as a new member who
   has been part of W3C for a few months and is interested in decentralized
   technology and verifiable credentials, currently leading a startup focused
   on safe, fair, and trusted digital experiences (00:01:20 <#00:01:20>).
   -

   *Community Updates* Manu Sporny reported that Brent Zandelle, chair of
   the Verifiable Credentials Working Group, discussed the next steps for
   verifiable credentials during yesterday's meeting, noting that seven
   specifications achieved global standard status two weeks prior (00:03:02
   <#00:03:02>). The group discussed continuing incubation, with some
   specifications automatically moving to the VCWG and others requiring the
   VCWG to be rechartered (00:04:12 <#00:04:12>).
   -

   *Confidence Method Specification* Manu Sporny detailed updates to the
   confidence method specification, including modernizing references to VC
   Data Model 2.0 and data integrity specs, updating the status to
   experimental, and adding definitions for conforming document and processor (
   00:07:55 <#00:07:55>). The data model section was largely untouched,
   while examples were updated to include JSON Web Key and multikey, and
   discussions on biometrics are needed. Security and privacy considerations
   were added, emphasizing selective disclosure and caution against
   unnecessary biometric use (00:10:23 <#00:10:23>).
   -

   *Authentication vs. Confidence Method* Manu Sporny raised the question
   of whether the confidence method should be renamed to authentication and
   aligned with authentication mechanisms in DID and CID documents (00:12:59
   <#00:12:59>). Dave Longley suggested that if the group agrees, the
   examples should be changed or an issue should be added to propose this
   change, also noting considerations for verification method retrieval and
   potential need for mapping or layering (00:14:10 <#00:14:10>).
   -

   *Verification Method Properties* Manu Sporny highlighted that if
   confidence methods are verification methods, they typically require 'id'
   and 'controller' properties. Dave Longley countered that the SID and DID
   specifications allow referencing verification methods without expressing
   their full contents, suggesting this could apply here (00:15:23
   <#00:15:23>) (00:17:50 <#00:17:50>). They discussed the possibility of
   embedding key information, such as X.509 certificates, and the need to
   consider how existing algorithms work with or without explicit IDs (
   00:16:37 <#00:16:37>) (00:20:05 <#00:20:05>).
   -

   *Renaming and Relationship to Authentication* Manu Sporny proposed
   keeping the name as 'confidence method' for now and raising an issue in the
   working group to discuss renaming it to 'authentication' and its
   relationship to existing authentication mechanisms (00:21:56 <#00:21:56>).
   Dave Longley agreed, suggesting that even if the name isn't changed, the
   close relationship to authentication should be described (00:24:29
   <#00:24:29>).
   -

   *Biometric Portrait Image Example* Manu Sporny advocated for keeping the
   biometric portrait image example in the specification to facilitate a
   thorough discussion in the VCWG about its legitimacy and potential privacy
   implications (00:27:37 <#00:27:37>). They discussed how this could unify
   biometric checks and allow wallets to handle such credentials carefully, as
   well as enabling more privacy-preserving biometric mechanisms like
   templates and matching services (00:28:51 <#00:28:51>). Dave Longley
   supported this, emphasizing the potential to nudge the industry towards
   user-controlled and privacy-respecting biometric services (00:31:11
   <#00:31:11>).
   -

   *Decentralized Identifier Document (DID) Example* Manu Sporny questioned
   how a DID document fits into the confidence method, suggesting that if the
   type is 'did', it should match against the authentication mechanisms within
   the DID document (00:32:31 <#00:32:31>). Dave Longley agreed that this
   effectively serves as another extension point to leverage DIDs for
   increased confidence, clarifying that it pertains to the authentication
   relationship. They discussed the need to be clear about authentication
   while also allowing for interesting extensions related to authentication
   within specific DID methods (00:33:59 <#00:33:59>).
   -

   *VC Barcodes Specification PR* Manu Sporny introduced a pull request for
   the VC barcodes specification that adds algorithms to encode raw verifiable
   credentials as QR codes, addressing a missing base use case (00:40:30
   <#00:40:30>). The PR includes an example of encoding a birth certificate
   as a QR code to combat fraud related to breeder documents (00:42:01
   <#00:42:01>). The use of C4LD for binary compression was demonstrated,
   showing a significant reduction in size, and a debug mode for C4LD was
   added to the spec plugin (00:43:01 <#00:43:01>). The resulting QR code
   size for a short-form birth certificate was shown to be quite small (
   00:45:11 <#00:45:11>). The PR refactors the algorithm section to include
   'encode verifiable credential to QR code' and 'decode verifiable credential
   from QR code' algorithms (00:46:21 <#00:46:21>).
   -

   *Other Business and Upcoming Meetings* Manu Sporny mentioned that the
   data integrity group is covering quantum-safe crypto suites, VCPI and VPR
   are progressing, and a co-sponsor is still being sought for the verifiable
   credentials over wireless specification (00:47:41 <#00:47:41>). They
   announced the next meeting and a cancellation the week after due to
   conflicts, reiterating the goal to advance specifications for promotion .

Suggested next steps

*No suggested next steps were found for this meeting.*

*You should review Gemini's notes to make sure they're accurate. Get tips
and learn how Gemini takes notes
<https://support.google.com/meet/answer/14754931>*

*Please provide feedback about using Gemini to take notes in a short
survey.
<https://google.qualtrics.com/jfe/form/SV_9vK3UZEaIQKKE7A?confid=HTXoraWvwuSDyC2_iVaiDxISOAIIigIgABgBCA>*
📖 Transcript

May 28, 2025
CCG Incubation and Promotion - Transcript 00:00:00 {#00:00:00}


*Manu Sporny:* All right, welcome everyone uh to uh the incubation and
promotion call for the credentials community group. Um this is May 28th,
2025. Um I am curious as to why the transcription stopped automatically.
That is the first time I've seen that happen. It might have been because we
didn't have uh audio going through the line. Anyway, um I had to turn it
back on and hopefully that doesn't break the recording system. Uh anyway,
welcome everyone. Um our agenda is on the screen. Um today we're going to
be focusing on confident the confidence method specification uh and some uh
passes on that that um uh we've done over the past week. uh as well as uh a
new pull request to the VC barcode specification to make sure that we have
just the generalized uh QR codebased verifiable credential stuff in there.
Uh and we can cover any other uh uh progress that has been made uh over the
past week. Um uh we usually uh start out with introductions and uh
reintroductions uh for folks that haven't been here in a while.


00:01:20 {#00:01:20}


*Manu Sporny:* Um, uh, we'll move on to community updates, uh, and then
we'll move into our main agenda topic. Um, so, uh, Vicas, I don't know if
you want to, um, uh, think about what you might want to say here in a
little bit. Uh, but we'll start off with, uh, introductions. Are there any
other updates or changes to the agenda today? Anything else that we want to
cover today? Okay. Uh if not, uh Vicass, would you like to introduce
yourself? It's totally optional. Um
*Vikas Malhotra:* Yeah, absolutely. Thank you so much uh Manu. Uh hello
everyone. Um I am uh I've been member of W3C for uh for a few months now
but I've not been very regular in these meetings. Um my name is Vicas
Malhotra. I am a 30y year uh veteran in digital space. uh have worked in uh
uh some uh very big projects out there. uh in my past life at present I'm
leading a project uh which is uh startup WPI technologies and uh it is uh
uh building uh a new edge u as I as I call it uh which is uh you know built
with being built with a vision of making our experiences as we work play
learn live to be safe fair trusted uh very much interested in the
decentralized uh uh technology set and um also the verifiable


00:03:02 {#00:03:02}


*Vikas Malhotra:* credentials and all those things that come along with it.
Uh so been working uh for about last four years or so in in uh such uh such
uh environments. Uh thank you so much for having me here.
*Manu Sporny:* Wonderful. Um, uh, that's great. Uh, and wonderful to have
you here. Uh, Vicas, welcome to, uh, the community. Um, uh, all right. Uh,
I think I'm not seeing anybody else that's new. Uh, so we'll go into
community updates. Um uh the only one I have is that uh yesterday during
the credentials community group meeting uh Brent Zandelle uh who is the
chair of the verifiable credentials working group at the W3C uh went over
uh what is next for verifiable credentials. So, for those of you um that
haven't heard yet, uh we were able to achieve global standard status for
seven of the verifiable credential family specifications two weeks ago. So,
that work is done uh after many years uh in the in the standards process uh
which is great.


00:04:12 {#00:04:12}


*Manu Sporny:* We have another set of work items that we also discussed
yesterday which is what we are incubating in this group here um in the plan
on what happens in August and what happens at W3CT. All of those things
were uh you know discussed today uh discussed yesterday. Uh the minutes are
out on the public uh credentials mailing list. Um uh those went out
yesterday uh just automated uh and it did a good job of kind of capturing
um everything that we're working on. Um the outcome kind of of that
discussion was that you know we are going to continue incubating in
finishing these specifications up. Some of them will just automatically
transition to the verifiable credential working group because the work is
in scope. I'll go over what those items are. Um and then some of them are
going to require the verifiable credential working group to be rechartered.
Um uh the W3C staff that's in charge of that process was at the meeting
yesterday and they heard about you know what that could uh look like.


00:05:17


*Manu Sporny:* So um that's good as well. Um uh meaning that you know we're
not going to lose a lot of momentum. there's, you know, we're going to be
able to feed um some of the more obvious specifications that are in charter
into that group from this group and then we'll be able to recharter um have
a rechartering discussion for the rest of that stuff. Um and we'll go over,
you know, what what some of those items are uh today. Um any questions,
concerns on that before we move into our main agenda? Okay. If not, let's
go ahead and move into uh the main agenda. Um the and actually these these
one of these links is broken I think. Um I think this got changed to BC
confidence method. Let me make sure that that's right. Yes. So that is the
new spec there. And then uh I don't know if this one stayed the same or if
we updated it. Um that one's still the same.


00:06:30


*Manu Sporny:* Uh okay. Uh so uh the specifications that were covered
yesterday um and specifically talking about what's in scope for the the uh
VCWG charter uh charter see I think let me yeah this is yeah this is the
latest charter um and specifically the things that are you know basically
we're in maintenance mode for the verifiable credential working group right
now uh so we can't create any new recommendations um and we cannot create
any more class 4 changes except for reserved extension points like
confidence method and render method uh And it was debatable whether
credential refresh was also under there. It probably is. Um and then
serious security issues. Uh and aa we're allowed to make those changes to
the specification. Uh so still much to do here. At least six months of work
probably just in this alone. Um and that'll keep us busy for the the better
part of uh this this next year or the better part of the la latter half of
this year. um those cred those specifications are specifically VC rendering
method, confidence method, which we're talking about today.


00:07:55 {#00:07:55}


*Manu Sporny:* We're talking about rendering method today as well, a
confidence method, and then we need to figure out what we want to do about
credential refresh. But there are at least three specs this group is
working on that probably need to be handed off to the VCWG at the end of
the summer, which means that we need to get them in in good shape uh to do
that. Um there's some process stuff that we want to do as well like
publishing a final credential final community group specification and and
things of that nature. Um okay, any questions, concerns about that? All
right, let's go ahead and jump into uh the confidence method specification.
So, the confidence method specification is a specification that we said
needed some serious uh work. Um, I this past weekend took a bit of time to
clean it up and get it into a shape that uh we could at least discuss it in
in this group. Um, the the contents of the spec was just like a copy paste
dump from the main spec when we removed the confidence method from the main
spec.


00:09:04


*Manu Sporny:* Um uh so I went through and updated it to make the proper
references to the main spec and um update the examples and and get rid of
the errors and and just modernize the the specification largely. Um so what
we have right now is that kind of that updated specification. Um the
abstract now refers to the VC data model 20 because it exists out there. Uh
any references that it makes points to like any terminology that it uses
uses the officially global standard terminology and references to it in the
VC data model. Uh spec um status of the the document was updated to say
this is an experimental spec right now. um uh updated the introduction a
little bit to link to the appropriate you know terminology but high level
things were kind of kept the same terminology we kind of defer back to the
VC data model and the data integrity spec um so that was updated uh I added
definitions for conforming document and conforming processor to match what
we had in our other specifications um so largely just kind of like
editorial work.


00:10:23 {#00:10:23}


*Manu Sporny:* Um the data model, this thing I didn't touch. Um I just kind
of left it left the text largely as is. Um which we'll want to discuss
today. Um, and then the examples I kind of updated um to use things like
JSON webkey and multike key and and last week or two weeks ago we said we
also want to did you know to be able to be used here and then there was
language on like using a biometric um in here that we need to talk about uh
as well. So, I just kind of jenned up some examples there for kind of
people to to look at. Um, going down to like security and privacy
considerations, they were blank. And so, I added some like bullet points on
like, hey, you know, confidence methods can be selectively disclosed and
verifiers need to be aware of that. They can't just presume that, you know,
a confidence method is going to be selectively disclosed to them. They have
to ask for it specifically. Um, in privacy considerations, we, you know,
want to talk about like, hey, as a holder, you don't have to like expose
these confidence methods to a verifier if they don't ask for them.


00:11:36


*Manu Sporny:* You don't have to expose a biometric photo if they don't ask
for it. Uh, and and and you don't have even if they ask for it, you don't
have to expose it. So, we should talk about that in the privacy
consideration section. Um uh and then of course the strong advice against
using biometrics like just if you don't need to for your use case don't do
it. Um there other potentially better ways of of getting higher levels of
assurance without leaking biometric information all over the place. Um we
might also want to talk about like you know using facial vectors instead of
uh pictures and and things like that. Um so a lot to be considered here. if
we go down if we support biometrics as a as a mechanism which I think we're
all a bit loathed to do unless it's like you know a high security uh use
case like boarding an airplane or something like that. Um okay so those are
the updates that were made on the confidence method specification. Um, one
of the other questions that came up while working on it is like, you know,
in the working group we were like, hey, we should have a confidence method
thing and that allows you to raise confidence on what a who if if the
subject is in fact the same subject that you know uh uh interacted with the
issuer, right?


00:12:59 {#00:12:59}


*Manu Sporny:* So, is this person standing in front of me the same person
that stood in front of the issuer when they got their credential or went
through their identity vetting process or whatever? Uh, or is this someone
totally different? Um, like I, you know, some use cases require you to know
that. Um, but fundamentally it, you know, in in working on, you know, some
of this language, uh, it really seemed like confidence method is just
authentication. like you're just trying to authenticate the subject. And I
was wondering, you know, if we could just reuse the authentication mechan
mechanisms we already have in decentralized identifier documents and
controlled identifier documents. Like why aren't we just reusing that? Like
you know, they can authenticate with a multi key, they can authenticate
with a JSON web key. I think we'd have to put some thinking into what does
an authentication method of decentralized identifier document mean? The
answer being like you can use any one of the authentication mechanisms in
the DID or the or the the controlled identifier document and then you know
what does authenticating with a biometric portrait image you know entail.


00:14:10 {#00:14:10}


*Manu Sporny:* Um and then the question is do we change this before we put
it in the working group or do we have that discussion in the working group?
Um okay so let me let me stop there and like let's let's hear what other
people have to say about this. You know, I I I'm fairly convinced that we
should just change this to authentication and it should align with
authentication and did document or sit document. Um, same purpose. Um, go
ahead Dave.
*Dave Longley:* Yeah, it might make sense to do that and either and if the
group here agrees that it does, we should change the example or add an
issue that suggests that we change that. Um, there are other considerations
when that's done like maybe these examples should not have uh IDs in them
if the point is to embed some new verification method that was signed over
by the issuer. um and then we'd have to understand what it would mean to go
about verifying something like this. So I I think one of the expectations
for performing authentication is putting a proof on a verifiable
presentation when you present something or may maybe you don't present
anything else.


00:15:23 {#00:15:23}


*Dave Longley:* You just put the proof on there. Um, and we have to walk
through how uh verification method retrieval works in the specs that we
have today and whether or not that would be a problem with just declaring
these things in here. Uh, so there might have to be some kind of mapping or
extra layering that would go into this spec to make that work properly. And
we probably want to have examples of places where you put the ID and the
and the type, but you leave out the other information because the
expectation is you're going to go fetch that. So it might be that there
there are two options here. You either put the ID and the type and then the
verification method is fetched or you just put a type and then you put the
other prop the other properties or at least the key material information
and then it's not fetched from anywhere and then we have to say how to deal
with that.
*Manu Sporny:* plus one to that. The the the thing that I I stumbled across
while I was doing the examples is that if these things are going to be
verification methods, unfortunately, uh we require ID in controller to be
specified for a verification method.


00:16:37 {#00:16:37}


*Manu Sporny:* Um, and so we either need to make an exception for that or
basically tell people like forget, you know, ignore that or create a new
base type, which I think would be very unfortunate. Um, uh, I do agree that
like we should have some examples that just use like an ident like a did
uh, you know, a verification method identifier um, where you don't embed
everything uh, in here. Um, the use case for embedding key information in
here is that if it's just like an X509Rert that's just off on its own, like
not tied to anything. Um, I think that was the thinking is that well, if
people want to use legacy X509 search, which some people do, uh, we can
just shove all that in a into a public key. Um, right in a JSON web key
public key value and the X509ert can kind of just live um, live there. Um
and then you get full chaining back to you know PKI existing legacy PKI and
stuff like that. Um so plus one to like maybe we just want to me mention
the ID right now like we are required to put ID and controller if all of
these are verification methods.


00:17:50 {#00:17:50}


*Manu Sporny:* We're required to put ID and controller uh in type. Those
are the three things that must exist on a u verification method. Um,
*Dave Longley:* I'm
*Manu Sporny:* go
*Dave Longley:* going
*Manu Sporny:* ahead.
*Dave Longley:* to go ahead and challenge that because the the SID docu uh
spec and the DID spec allow you to reference verify uh verification methods
uh from their their home document and since this would not be the home
document in that case I think you should it would fit in with the language
that you can reference it and so we should check that but it is certainly a
thing that you can reference um ver uh verification methods without
expressing the contents about them.
*Manu Sporny:* Yeah, I'm very happy for that to be the the outcome. Like
that that solves that problem, I think. Um where is it? Uh verification
methods. It's here where we're like well we say it must be um so this
doesn't say they must exist but
*Dave Longley:* Yeah. And if you just if you go look


00:19:01


*Manu Sporny:* uh
*Dave Longley:* at
*Manu Sporny:* here
*Dave Longley:* there's
*Manu Sporny:* it's it's here. It's it's this language that I must
*Dave Longley:* yeah
*Manu Sporny:* include.
*Dave Longley:* that's that's not that's about the verification method
property itself. That's not about the object. And if you scroll down and
look at some of the other verification relationships, those can reference
uh things
*Manu Sporny:* Yeah,
*Dave Longley:* that
*Manu Sporny:* that's
*Dave Longley:* exist
*Manu Sporny:* true.
*Dave Longley:* in the verification method or outside of the document
itself. And so we added some language somewhere in here that talks about
the the home document or I don't remember what we ended up calling it. Um
but where the verification method is actually defined those those
properties have to be present. But if you're referencing it they I think we
say they can't be present.
*Manu Sporny:* Yeah, refer. Here we go. Referring to Yeah, I mean this is
this is the strongest I think this is the strongest uh argument for you
don't need controller. um ID exists in all of these things, but you know,
we could basically say, look, if you're just embedding it directly, you
know, and you don't want it to have an ID, then that's fine.


00:20:05 {#00:20:05}


*Manu Sporny:* I I think there's I think there's at in the very worst case,
we can basically say, you know, those other normative statements over
there, those don't apply. even if they did apply, we can basically in in
the spec say no, like we want to be able to talk about public keys without
them having an ID or a controller because, you know, we want to be able to
cover like chip card uh examples like literally the key is embedded in the
chip card and the and the credential subject is the card itself and the way
you authenticate the card is through a public key PKI that you know exists
only solely in the cards and so it doesn't have an identifier, right? Um,
*Dave Longley:* Yeah,
*Manu Sporny:* go
*Dave Longley:* I
*Manu Sporny:* ahead.
*Dave Longley:* think all that's fine. Um, but we just have to consider how
the existing algorithms also work so that we can make sure people can don't
have to change too much of their software to actually authenticate uh to
actually check proofs produced by these things.


00:21:03


*Manu Sporny:* Yep. Yeah. So, you're saying maybe we do want to put an ID
because in in the proof you're going to
*Dave Longley:* Uh,
*Manu Sporny:* have to have an ID.
*Dave Longley:* no. Um, it could be that this specification says if no ID
is present, here's what you do. You you generate some shared identifier or
something so that it will work with the algorithms
*Manu Sporny:* Yeah, I'm trying
*Dave Longley:* and
*Manu Sporny:* to figure out what a proof without, you know, in the
verification method for a proof what it says if we don't have an ID in here
or, you
*Dave Longley:* Well,
*Manu Sporny:* know,
*Dave Longley:* it could be some localized ID. It could be some shared ID
that is defined. You know, we have to walk through this and see if it makes
any sense. But it could be that if there's no ID present here, then this
spec says you generate this controller document and you use this ID and
then the software knows what to do with that because we'll know how to to
retrieve that on the basis of having a VC.


00:21:56 {#00:21:56}


*Manu Sporny:* Okay. All right. So, that is something to be I think
discussed in the working group. Um, okay. Any other opinions on whether
this should be authentication or we should create a new property like
whether we should basically do the same thing we've been doing for
authentication and said documents and did documents or if we should like
yeah any other thoughts on that before I inject my
*Dave Longley:* I'll just make one other comment that one of the things we
might want to write down is you could perhaps autogenerate the ID as a URL
with a JSON pointer into the VC where the material is. So there there are
some automated things we might want to do um to make that
*Manu Sporny:* Okay, makes sense. Um, okay. Um, all right. So now for the
question of like do we want to rename this now or later? I I'm leaning
towards do it later because if we name this you know authenticating and
blah blah blah blah blah then all of a sudden we have a big discussion in
the working group on whether or not this is the same thing or not.


00:23:16


*Manu Sporny:* Whereas if we just keep it confidence method for now we can
raise an issue on it. say the working group has to decide this because the
working group really does have to decide it. Um and then um that becomes
kind of the discussion in the in the working group. Um and then there's a
question on like what about the reserve confidence method property? Do we
deprecate it? I think we end up doing a version 2.1 of the verifiable
credential vocabulary uh where we deprecate confidence method and uh add in
authentication. Um go ahead Dave
*Dave Longley:* There might be advantages for keeping it that that are
related to this autogeneration stuff we're talking about. It might just be
when you see competence method, you have a list of things that are either
verification methods or other things and there's some transform to put it
into authentication space. So you can authenticate proofs with purpose
authentication. So there might be an advantage to keeping it. I I would
recommend adding an issue to the spec that there's a discussion to be had
around changing it to authentication or or figuring out its relationship to
authentication.


00:24:29 {#00:24:29}


*Manu Sporny:* Yep. Um should confidence method be rename renamed to
authenticate authentication. Uh currently the the the examples in the
specification verification methods here. Um, do we want to rename Okay. Um,
*Dave Longley:* I I guess the only other comment there would be um if we
don't even if we don't rename it, we should describe the relationship to
authentication since they seem very closely connected.
*Manu Sporny:* All right. All right. And that we will deal with in the
working group. Um let's see. I kind of added this did confidence method
example but we didn't talk about it depth. Um did confirmation to the list
of confirmation methods. Yeah, that that feels like the same as this one.
Um, uh, it's David Chadwick here. I was hoping that we'd be able to discuss
his
*Dave Longley:* He
*Manu Sporny:* thing
*Dave Longley:* is not
*Manu Sporny:* here.
*Dave Longley:* here today.
*Manu Sporny:* Okay. So, let's hold off discussing that until he's here.
Um, and then we just raise this one.


00:27:37 {#00:27:37}


*Manu Sporny:* Okay. So um I would like to get feedback from the group on
this biometric portrait image example. Um I I think it would be a good idea
for us to keep this in there so the group can have the verifiable
credential working group can have a very thorough discussion around is this
legitimate or not. Um I I think there's I one of the benefits here. So So
if we look at something like a driver's license, um a driver's license or
or any kind of identification card, um they uh have your portrait image in
them and it's handed over and there's no selective disclosure of it. um uh
in in kind of full disclosure um um uh crypto suites in selective
disclosure crypto suites you can selectively disclose that that sort of
stuff. Um so it's arguable that like we don't really need this in the
confidence method because you know that it has the the uh biometric there.
The thing that changes it here is that you know this unifies the way that
you would do a biometric check.


00:28:51 {#00:28:51}


*Manu Sporny:* Um, it it helps a wallet kind of basically say like, hey,
this this thing definitely has biometric information in here. There's a
confidence method that's biometric portrait image that it's got a biometric
in there, so be careful with this credential when you hand it over. Uh, uh,
digital wallets can be set to just like not hand that stuff over by
default. Um, they have to be specifically asked for um, in the confidence
method. Um uh the other kind of uh you know benefits here is that we can
use more privacy preserving biometric mechanisms. So instead of including a
picture slightly more privacy preserving are biometric templates um where
it's like you don't get any image data and the only time you can kind of
match it is if the person's standing in front of you. That is not always
true though because there are ways of kind of statistically generating what
the person might look like from a biometric vector. Um so certainly from
like a a fingerprint template, right? Uh but even from like an iris
template or a a facial template, there are some, you know, ways of encoding
that data so that it's like you can kind of tell more or less what the
person looks like because there's enough data in there.


00:30:07


*Manu Sporny:* Um, but there there are privacy preserving more privacy
preserving ways to do biometric matching there where it's like even if you
store the the biometric template, it might not um you're not storing an
actual picture of the person. Slightly better, but not not super great. Um,
and then there are all kinds of like biometric matching services that could
be used. like imagine a future where you're like you know what I I want to
choose my biometric matching service. So if if there is, you know, if if it
is required, if I'm in a kind of highsecurity kind of use case and it's
required that biometric template matching is done, I want to choose the
provider that's going to do that. As long as the verifier accepts the
biometric matching provider, um, then that's all that's required. And none
of my video information or picture information or even my picture goes to
the verifier. The only thing that ends up going to the verifier is a yes,
we just did a successful live match or no, we did not do a successful live
match.


00:31:11 {#00:31:11}


*Manu Sporny:* Um, I think that kind of discussion would be a very good one
for the BCWG to have. Um because there are way better ways to do if the use
case requires biometric matching. There are way better ways that we can
nudge the industry towards doing that versus the the fairly invasive like
you send a video stream, you know, to some completely unknown biometric
backend who is doing who knows what with the video stream information, your
audio, your your you know your facial image, you know, all that kind of
stuff. Um so I think having that uh and we might want to add an example uh
biometric you know matching provider to kind of trigger that that use case.
Um thoughts from the group. Good idea, bad idea.
*Dave Longley:* I don't think the minutes record thumbs up. Um I gave you a
bunch of thumbs up. Um I I agree with all of that. I think it would be
really good for the group to be discussing it and to have the solution uh
nudge the industry in in a way that uh allows users to have control over
biometrics, biometric services that they that they choose to use so that
there's good competi healthy competition in the space to give to give
people better privacy.


00:32:31 {#00:32:31}


*Dave Longley:* So I think all all of those are uh good reasons to have
that conversation and to push the design in that
*Manu Sporny:* Okay. Um, sounds good. Anyone think that's a bad idea? Any
other comments? All right. Um, I will add a biometric matching service
thing here just to I guess I'll I'll try to add a biometric template and a
biometric matching service just so we can have a full kind of discussion on
that stuff. Okay. Anything else on biometrics before we move on? Okay. The
the final thing is I didn't know how to make a decentralized identifier
document fit. I think it's just like if you have this type and it's a did
then you just match against the authentication mechanisms and it's not
specific about the verification method. You just match against the I don't
Yeah, I don't I don't know if we need to do anything. I don't know what
else we would need to do here. Go ahead, Dave.
*Dave Longley:* I think there's a if I remember correctly a restriction
that a type has to be present here for the uh value and if if a type has to
be present then we have to come up with something otherwise you could just
put a URL here and if it starts with did then you're supposed to know what
to do uh the spec will say you know what to do it starts with a did um but
if we


00:33:59 {#00:33:59}


*Dave Longley:* have to put a type we can invent type and we'll sort that
out but I think it's right I think what's being said here is your
confidence method is uh you can use a did document to increase confidence
and then you can use whatever's in that DID document. Um, and it's
effectively another extension point that lets you use the world of DIDs to
increase confidence.
*Manu Sporny:* Okay. And would the language basically be like you go to the
authentication mechanisms and the the authentication methods in the did
like I don't think we we don't want to basically say you can use anything
in here, right? Because we don't mean it for like capability delegation or
assertion method. It's it's literally like use the authentication
*Dave Longley:* Yeah,
*Manu Sporny:* relationship.
*Dave Longley:* we have to talk about authentication one way or the other
like in that issue and I think that's what we would talk about. Um I don't
think we necessarily want to preclude other interesting extensions that a
particular DID method might do something about related to authentication.
Um so we when we talk about ds we might want to say be clear this is about
authentication and but if you're authenticating also uh like if an issuer
is going to sign this field they should know which method they should
understand the method that's being signed and understand it might have
additional authentication somethings that somebody using that method could
could use to uh to authenticate.


00:35:26


*Dave Longley:* If that made sense.
*Manu Sporny:* Yeah, I think it did. Um, okay. I think that is the gamut of
things we'd want to put in confidence method or authentication, whatever we
end up calling it. Did we miss anything? Are there other ways of
authenticating that we want to cover here? Like dancing a wiggly dance or I
don't something that is not entirely
*Dave Longley:* I think those things will get removed if we put them in.
Um, so I I think I think this is good enough to have a a discussion about
it in the working group. Um, and we know that if we don't have by the time
the working group's done with this, if we don't for any one of these
examples, if one of if we don't actually have something that someone can
implement, it's going to get removed because that's been a rule in the
*Manu Sporny:* Yep. One other thing that I'm wondering here is for the
biometric services um if a protocol is also associated I mean it's like I
think a protocol is associated with all of these right I mean it's it like
the the the the protocol for multikey and JSON webkey is like you're doing
some kind of presentation and the presentation has the you know a proof on
it that matches um same thing for decentralized identifier document.


00:36:59


*Manu Sporny:* Uh biometric portrait image is a little less like I mean
it's kind of like do you match the picture or not? Um and then that's up to
whoever that's doing the matching. But when we get into like biometric
service provider then there's a presumption of there being a protocol there
like what's the protocol for the video stream? What's it what's the
protocol for the image being sent? You know what's the return value? Uh
wondering if we need to start design documenting those those or if we need
to document that kind of thing. Go ahead, Dave.
*Dave Longley:* Well, that kind of thing is if it's going to survive in the
spec, as I was mentioning, is either going to have to be documented or
called out as some kind of extension point thing. Um, we're going to have
to do something and it's unclear if we'll if it will make sense to do so in
the spec. Maybe there's some really simple uh matching service that we
could create that people could implement that is like the the baseline for
doing this.


00:38:00


*Dave Longley:* Uh it's it's a it's a tricky space because we want to allow
people to innovate here and we don't want to overstep, but we also can't
underst or it'll just get removed. So I don't I don't know what the CG
wants to do about this. If anything, certainly the working group has to do
something or it will end up, I guess, maybe just being mentioned in some
text somewhere as an option, but it won't be in the examples, I wouldn't
think.
*Manu Sporny:* Yep. Okay. And then maybe we can get some comments from ACLU
EFF on their thought. I mean, I'm sure they're going to have some pretty
strong feelings about this stuff. Um, and as well as biometric service
providers that, you know, want to want to provide more uh privacy
preserving, you know, mechanisms.
*Dave Longley:* Yeah, some of them want to come into the group and put
together some kind of spec that allows them to interoperate. That would be
the best That would be the best outcome, I
*Manu Sporny:* No, that's one of that.


00:39:09


*Manu Sporny:* Okay. Uh, all right. I think I have some concrete changes
that I can make to this and then it's going to be ready. I think like I
don't think we want to do any other changes before the BCWG gets a hold of
it. Um, and I'll move it up. Uh, I'll move confidence method up into here
once I make that pass. Um, of course, anyone can come come along and add
PRs or issues or whatever like um, clearly. Okay. Anything else on
confidence method before we go on to render method? All right. Um that is
that and let me open up render method next. All right. I raised a PR on
render method. I thought I raised a PR. What did I do? Did I not push that?
What happened? Hold on one second. I might have forgotten to push No,
sorry. I'm totally totally wrong spec. Um, we have so many that we're doing.


00:40:30 {#00:40:30}


*Manu Sporny:* VC barcodes. Sorry, it's not render method. It's the
barcodes thing. Um, I opened a PR. So, TED, I totally missed. Whoa, we need
to process this. Uh, this is from last year, July. um uh raised the PR um
to add the algorithms to encode raw VCs as QR codes. So, the VC barcode
spec talked about like how do you encode into PDF417 or uh and MRZ um
machine readable zone uh cards, but we like totally didn't talk about like
the base use case for barcodes, which was the um the QR code um like being
able to just take a VC and put it into a QR code. So, that's what this PR
does. Let me see if like uh yeah it doesn't have the let me sites local see
bar codes. Let me try and see if yeah this is the this is the one. So the
the spec uh has like you know what if you want to take a a verifiable
credential and like really compress it down into something that can fit on
the back of a driver's license like the bottom 3/10en of an inch here cover
a verifiable credential that's like 185 bytes in size that secures the data
on the back of the card.


00:42:01 {#00:42:01}


*Manu Sporny:* Um, or this is like an employment authorization document,
which usually has MRZ data on the back. The MRZ is machine readable zone,
and it's the thing that shows up on passports and travel documents. Um, so
how do we add a QR code on the front of the card that binds to the
information on the back of the card? Um, so there's that. Uh but we were
missing like what happens if you have like a a verifiable credential like a
birth certificate like a short form birth certificate and you just want to
encode the entire thing as a QR code and put it onto a piece of paper. So
this is uh this is a new section here in the pull request. It adds a birth
certificate example um fake one you know Utopia Commonwealth of Utopia and
it puts a QR code in the bottom right that can be scanned and verified as a
verifiable credential. So, um this is meant to combat um fraud when
creating uh uh breeder documents that are used for driver's licenses and
passports.


00:43:01 {#00:43:01}


*Manu Sporny:* So, um, birth certificates, death certificates, marriage
certificates, uh, divorce certificates, you know, all those all those kinds
of things, a change of name, um, all of those things currently are printed
on like special pieces of paper, uh, that in theory nobody has access to,
but turns out that, you know, uh, lots of people can can, you know, um,
easily, uh, modify the information on the document or or create a new one,
um, uh, depending depending on uh depending on you know the type of uh
technologies that are used to protect it but none of them that we know of
have digital signatures um on on here. Um yes the barcode Dmitri is uh
Seabore LD encoded. So down here we added a a new feature to the the
respect plugin for verifiable credentials that will take a bog standard
verifiable credential in version 20 format. It'll do the previous formats
too, but this one's, you know, version two. And then it will show you the
tab of the binary compression that that we do. So, this is what the actual
binary data uh looks like.


00:44:13


*Manu Sporny:* Um, we still need to update to the latest version of C4LD.
But as you can see, like it drops from a kilobyte down to 438 bytes, about
60% compression. And that's without special tuning. You can even special
tune the C4LD to get it smaller. Um so this is the seabore LD payload and
then we also have a debug core LD diagnostic mode to show you like these
are all the things that compressed and these are the things that didn't
compress. So for example this vital records vocabulary didn't the URL
didn't compress because we don't have an entry for it in the in the table.
It's experimental. Uh and that's fine like core LD will compress as much as
it can and for the things it doesn't know how to compress it won't compress
it. Um, we're not compressing date times here because this, you know,
JSONLDD context doesn't specify this as a datetime value. If we change
that, it would compress down even smaller. Some of the text we can't, you
know, compress.


00:45:11 {#00:45:11}


*Manu Sporny:* Um, and then the URL for the issuer. We didn't, you know,
compress. Um, but the signature compresses, you know, fairly well. The time
in the signature compresses well, so on so forth. So that'll show you like
we now have like a seabboard LD diagnostic mode that we can put in
specifications so people can check their uh implementations against what's
in the spec and then of course we will then take this binary uh and render
it as a QR code. So this is this is that entire you know this entire
verifiable credential which is the entirety of a short form birth
certificate in the United States. So this is if you get a birth
certificate, a short form birth certificate in the United States, this is
the information that's in it uh that's required to be in it and this is the
size of the QR code that's generated as a result of that. So pretty tiny
can put it on a birth certificate no problem. Um, one of the mo more
exciting things is like we've done a full full form birth certificate, like
a four-page document, and it's like it's about four times as large as this
QR code, but it's definitely something you can easily still put on a piece
of paper.


00:46:21 {#00:46:21}


*Manu Sporny:* Um, it'll take up, you know, about a 2 in x 2 in square, uh,
3 in by 3 in if you really want to be, you know, um, uh, make sure that it
it can scan. Um, okay. So that uh example was added here and then um the
algorithm section was refactored a bit um to add uh two new algorithms and
code verifiable credential to QR code. So it's just this this is the
entirety of the algorithm. It of course calls out to the seabore LD spec to
do a lot of the heavy lifting. Uh it calls out to the SIDS spec to do the
base encoding. Um, but that's, you know, basically the algorithm to encode
and this is the algorithm to decode. Um, and I think it's complete. Um, I
don't think we're going to have to modify it much. Um, okay. So, this this
is B this PR basically just adds generalized encode any verifiable
credential to a QR code. the algorithm for that along with the you know if
you want to put it in an MRZ or if you want to you know protect a a barcode
and that I we think that covers the vast majority of barcode like identity
document barcode formats in the in the world.


00:47:41 {#00:47:41}


*Manu Sporny:* Um if we need to add another thing like data matrix fairly
easy thing to do um not not super difficult to do that. Um yeah okay so
that's kind of where we are. Any thoughts, concerns, comments about this
change? All right. Um, I think that's it. That's our agenda for today. Um,
are there any other items folks wanted to cover today? All right. And just
as a heads up, you know, data integrity group on Fridays is covering the
quantum safe crypto suites and that incubation VCPI is moving forward uh as
as is VPR verifiable presentation request. Uh David Chadwick and Isaac are
working on updating this one. Um and then we still are looking for a
co-sponsor for the verifiable credentials over wireless specification. I
have not sent that request out to the mailing list yet. Um but if anyone's
interested in co-sponsoring that with us um that just means like you are
supportive of it as well. Um uh please let us know. Okay, I think that is
it uh for the agenda today. Uh thank you everyone uh for attending um and
the interest. Uh we will meet again next week. Um, and then the week after
next, we won't have a call um, due to some meeting conflicts. And we'll
just keep plugging away at these items until we've moved everything up to
specifications, ready for promotion uh, stage. All right, thanks everyone.
Have a wonderful rest of your week and we will meet again next week. Take
care. Bye.


Transcription ended after 00:49:43

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