search

w3c-ccg / community

COMMUNITY: W3C Credentials Community Group Community Repo
https://w3c-ccg.github.io/community
Other
42 stars 6 forks source link

W3C VCDM Confidence Method Extension #245

Open awoie opened 1 year ago

awoie commented 1 year ago

New Work Item Proposal

The proposal is about defining a new property for the W3C VCDM that acts as an extension point that allows an issuer to include one or more Confidence Methods in a verifiable credential to inform verifiers of mechanisms they could use to increase their confidence in the truth of a variety of things, including the following:

See the following ...

NOTE: The idea was originally to define and add the new property to W3C VCDM 2.0 but the group decided that it would be good to incubate the property in W3C CCG first (in case there is interest). More context information about the latest discussions can be found here:

@awoie also presented the idea on a W3C CCG Call. Back then the proposal was still called "confirmation method": https://docs.google.com/presentation/d/1-uPVyl3S-vPvy4HqL6BcjN0xTu9AvqxFfwowqwzcXpo.

Include Link to Abstract or Draft

List Owners

I hope that we find one more co-owner in the W3C CCG community to own this.

Work Item Questions

Answer the following questions in order to document how you are meeting the requirements for a new work item at the W3C Credentials Community Group. Please note if this work item supports the Silicon Valley Innovation program or another government or private sector project.

  1. Explain what you are trying to do using no jargon or acronyms.

How can the verifier trust that the entity, the one the issuer issued the verifiable credentials to, presented the verifiable presentation and the entity did not simply get a copy of the included verifiable credentials.

  1. How is it done today, and what are the limits of the current practice?

There is no standardized way of how this can be done. Implementers are using Verifiable Presentations but there are a few issues with this approach:

Implementers are using something like the following to achieve this goal but note that this would only work for naive cases where the holder and the subject have identifiers that allow to the verifier to obtain cryptographic material such as DIDs or public keys in general:

IF (holder.id == credentialSubject.id 
  AND hasAuthnMethod(resolve(holder.id), vp.proof.verificationMethod)
  AND isValid(vp.proof)) THEN
    Print “Holder Binding validated”
  1. What is new in your approach and why do you think it will be successful?

This is the first attempt to standardize this approach in form of a framework. It will be successful because it is an extension mechanism that can act as a big tent for all such methods that are used in the wild today, e.g., DID-Auth, Anoncreds, etc.

  1. How are you involving participants from multiple skill sets and global locations in this work item? (Skill sets: technical, design, product, marketing, anthropological, and UX. Global locations: the Americas, APAC, Europe, Middle East.)

This is the result of work started at the last Rebooting the Web of Trust in The Hague, which brought together a number of people from various countries: Austria, Germany, Netherlands, Spain, Norway, Greece, Canada, Italy, and more:

https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/identifier-binding.md

We hope to gather more feedback from the diverse community in the CCG.

  1. What actions are you taking to make this work item accessible to a non-technical audience?

The specification should attempt to provide a gentle introduction to the topic via a non-technical introduction as well as non-technical use cases with imagery that is accessible to the general population. Since the specification is technical in nature, I'd be curious to learn more about other mechanisms that could be used to make the specification more accessible to a non-technical audience.

msporny commented 1 year ago

Digital Bazaar is supportive of this mechanism as one of the mechanisms that can be used to establish confidence that an entity presenting the VC is associated with some aspect of the VC that the issuer intended. We feel like this mechanism is useful not only for holder presentation, but guardianship use cases as well. While we cannot put our name forward as a co-owner of the work (purely due to workload issues on our side, which might alleviate themselves in time), we do plan to watch the work closely and implement what we can for the use cases that fit what the specification can provide.

mprorock commented 1 year ago

Just needs two owners from different orgs to approve

OR13 commented 1 year ago

If we don't get 2 owners in a few weeks, I suggest we remove the reference from the VCWG document, and allow the community to pick up the work, when there is interest.

I don't think the VCWG should point to or comment on work that is not actually being incubated or done.

RieksJ commented 1 year ago

I think this work is valuable and I'm supportive but I personally don't have the time to work on it.

brianorwhatever commented 12 months ago

Aviary Tech would like to help this important work however don't feel qualified enough to be the main driver. Hopefully someone is able to step up for that role and we can help out 😄

brianorwhatever commented 12 months ago

After some confidence boosting from @dlongley I would like to take this on as the main driver as I have plans on implementing it in the near future. Is there anyone that would be willing to help support and guide me through the process?

awoie commented 12 months ago

This is really awesome, then I'll update the CCG workitem accordingly. I'll add you to the list of owners. I'll help with finding a co-pilot now.

On Tue, Jul 11, 2023 at 10:28 PM Brian Richter @.***> wrote:

After some confidence boosting from @dlongley https://github.com/dlongley I would like to take this on as the main driver as I have plans on implementing it in the near future. Is there anyone that would be willing to help support and guide me through the process?

— Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/245#issuecomment-1631466906, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKLN3MBXM7B57TUUJHAWIWTXPWZQJANCNFSM6AAAAAAZVNPP6I . You are receiving this because you authored the thread.Message ID: @.***>

awoie commented 12 months ago

@decentralgabe also volunteered to be one of the owners, so I'll add him. I'll be also a co-pilot, can assist with guidance but won't have a lot of time for the next 2 months.

awoie commented 12 months ago

I guess, we now have three owners which allows us to start an official work item in CCG. Please advice what are the next steps.

decentralgabe commented 12 months ago

approved

ottonomy commented 12 months ago

Congrats on spinning up collaboration to think through these use cases on a work item. As different identifiers associated with credential issuers and subjects have varying capabilities for authentication, it's great to figure out some approaches to interoperability. No blockers from me.

But some questions and thoughts, in case they're helpful. I don't see a huge amount of differentiation between confidenceMethods and evidence. https://w3c.github.io/vc-data-model/#evidence or between confidenceMethods and other ways of expressing identifiers that have potential for verifiers to authenticate.

Evidence

Evidence is a method used to express data about the credential issuing process that the issuer relied on and wants to express to the holder and potential verifiers. It's assumed that evidence could increase the confidence of a verifier who is hoping to rely on the credential. Example use cases include describing an assessment process, or describing that the issuer consulted certain identity documents or authenticated a subject in a particular way. Evidence is described in the VCDM like this:

[Evidence] could be used by the verifier to establish the confidence with which it relies on the claims in the verifiable credential.

The value of the evidence property MUST be one or more evidence schemes providing enough information for a verifier to determine whether the evidence gathered by the issuer meets its confidence requirements for relying on the credential.

Maybe there is some value in expressing a particular piece of data for the purposes of expressing issuer confidence or expressing verifier confidence that would subtly be different from what can be done with evidence, but I don't see a significant difference between an effort to build an interoperable ConfidenceMethod that presents that data and an effort to build an interoperable Evidence scheme to present that data.

Other "identifier" Claims about a Credential Subject

I find it a little strange that the examples place the confidenceMethod inside the credentialSubject claim rather than applying it at the VerifiableCredential.confidenceMethod level like VerifiableCredential.evidence is. I'm not sure why a confidence method that essentially describes a public key associated with the credentialSubject would be a confidence method at all, rather than just a claim made about the subject ("the subject holds key X", using something like credentialSubject.verificationMethod).

For example, Open Badges 3.0 includes the option for the issuer to declare one or more identifiers that are associated with a credential subject. Then, if a verifier is not able to verify a credentialSubject.id or one is not included, the verifier could choose to verify one of the identifiers, such as an email address, nationalIdentityNumber, userName or a bunch of other options used elsewhere in 1EdTech's ecosystem. I guess I wonder why a claim that would read as English like, "the credential subject holds a cryptographic key" or "...holds an email address" would be a confidenceMethod rather than something a bit more semantically descriptive like verificationMethod or email.

Another example is the European Learning Model credentials. Some recent examples used the credentialSubject.id of urn:epass:person:1. This is not likely to be an identifier that anybody outside of the epass ecosystem would be able to authenticate a user for, but the credential also includes a contactPoint, which is an email address, expressed in their schema that the issuer had bound to the subject.

"credentialSubject": {
    "id": "urn:epass:person:1",
    "type": "Person",
    contactPoint": {
        "id": "urn:epass:contactPoint:1",
        "type": "ContactPoint",
        "emailAddress": {
            "id": "mailto:anthony@knowledgeinnovation.eu",
            "type": "Mailbox"
        }
    }
    ...
}

Identifier Binding

The RWOT paper defines Identifier Binding

The situation in which there is an identifier that a particular party has bound to some entity that it knows to exist, and has specified one or more means that other parties can use to identify and/or authenticate that entity. Such means are typically specified as part of a VC.

It almost seems more useful to me to express that a binding is between two identifiers, as opposed to between an identifier and an entity. That would be like how the credential above "binds" a "contactPoint" email address to another identifier, the urn:epass:person:1 id. Nothing about the above credential binds the email address to the underlying human being (that is being done internal to the issuer's and then verifier's processes), it seems to me to be more about binding multiple identifiers together, where there may be varying capabilities to authenticate an entity as those identifiers.

Both of the above additional-identifier approaches are expected to have interoperable implementations for the concept of expressing an additional identifier that a verifier might be able to authenticate against a subject entity (whether it's a human across a desk or with a session in a web browser). (Note: Pending finalization of the ELM selection of identifier schemes, this feels like a placeholder and I haven't tracked down a hard answer as to whether urn:epass is really what they intend to use)

TL;DR: maybe the community could coordinate to use existing 'evidence' and various credentialSubject types to accomplish confidence method use cases, as some implementation communities are already doing, instead of reserving a new extension point in the VCDM. But I don't desire to be a blocker to other groups of implementers solving for these use cases in the way they prefer.

awoie commented 12 months ago

I disagree, we had a lot of discussions why evidence is different from confidenceMethod. Please read through the discussions referenced in the issues in the work item description.

Essentially, evidence is something the issuer verifies to make trustworthy claims while confidenceMethod is something the issuer puts in a VC to allow the holder to prove they didn’t simple get a copy of the VC.

The confirmation method (cnf) in IETF (RFC7800) is very close to what the original intention of confidenceMethod was.

If I could I’d have even called it authenticator since the NIST definition comes also very close to what was requested originally.

On Wed 12. Jul 2023 at 23:02, Nate Otto @.***> wrote:

Congrats on spinning up collaboration to think through these use cases on a work item. As different identifiers associated with credential issuers and subjects have varying capabilities for authentication, it's great to figure out some approaches to interoperability. No blockers from me.

But some questions and thoughts, in case they're helpful. I don't see a huge amount of differentiation between confidenceMethods and evidence. https://w3c.github.io/vc-data-model/#evidence or between confidenceMethods and other ways of expressing identifiers that have potential for verifiers to authenticate. Evidence

Evidence is a method used to express data about the credential issuing process that the issuer relied on and wants to express to the holder and potential verifiers. It's assumed that evidence could increase the confidence of a verifier who is hoping to rely on the credential. Example use cases include describing an assessment process, or describing that the issuer consulted certain identity documents or authenticated a subject in a particular way. Evidence is described in the VCDM like this:

[Evidence] could be used by the verifier https://w3c.github.io/vc-data-model/#dfn-verifier to establish the confidence with which it relies on the claims in the verifiable credential https://w3c.github.io/vc-data-model/#dfn-verifiable-credential.

The value of the evidence property https://w3c.github.io/vc-data-model/#dfn-property MUST be one or more evidence schemes providing enough information for a verifier https://w3c.github.io/vc-data-model/#dfn-verifier to determine whether the evidence gathered by the issuer https://w3c.github.io/vc-data-model/#dfn-issuers meets its confidence requirements for relying on the credential https://w3c.github.io/vc-data-model/#dfn-credential.

Maybe there is some value in expressing a particular piece of data for the purposes of expressing issuer confidence or expressing verifier confidence that would subtly be different from what can be done with evidence, but I don't see a significant difference between an effort to build an interoperable ConfidenceMethod that presents that data and an effort to build an interoperable Evidence scheme to present that data. Other "identifier" Claims about a Credential Subject

I find it a little strange that the examples place the confidenceMethod inside the credentialSubject claim rather than applying it at the VerifiableCredential.confidenceMethod level like VerifiableCredential.evidence is. I'm not sure why a confidence method that essentially describes a public key associated with the credentialSubject would be a confidence method at all, rather than just a claim made about the subject ("the subject holds key X", using something like credentialSubject.verificationMethod).

For example, Open Badges 3.0 includes the option https://1edtech.github.io/openbadges-specification/ob_v3p0.html#achievementsubject for the issuer to declare one or more identifiers that are associated with a credential subject. Then, if a verifier is not able to verify a credentialSubject.id or one is not included, the verifier could choose to verify one of the identifiers, such as an email address, nationalIdentityNumber, userName or a bunch of other options used elsewhere in 1EdTech's ecosystem. I guess I wonder why a claim that would read as English like, "the credential subject holds a cryptographic key" or "...holds an email address" would be a confidenceMethod rather than something a bit more semantically descriptive like verificationMethod or email.

Another example is the European Learning Model credentials. Some recent examples https://github.com/Knowledge-Innovation-Centre/creds used the credentialSubject.id of urn:epass:person:1. This is not likely to be an identifier that anybody outside of the epass ecosystem would be able to authenticate a user for, but the credential also includes a contactPoint, which is an email address, expressed in their schema that the issuer had bound to the subject.

"credentialSubject": { "id": "urn:epass:person:1", "type": "Person", contactPoint": { "id": "urn:epass:contactPoint:1", "type": "ContactPoint", "emailAddress": { "id": @.***", "type": "Mailbox" } } ... }

Identifier Binding

The RWOT paper defines Identifier Binding https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/identifier-binding.md#identifier-binding

The situation in which there is an identifier that a particular party has bound to some entity that it knows to exist, and has specified one or more means that other parties can use to identify and/or authenticate that entity. Such means are typically specified as part of a VC.

It almost seems more useful to me to express that a binding is between two identifiers, as opposed to between an identifier and an entity. That would be like how the credential above "binds" a "contactPoint" email address to another identifier, the urn:epass:person:1 id. Nothing about the above credential binds the email address to the underlying human being (that is being done internal to the issuer's and then verifier's processes), it seems to me to be more about binding multiple identifiers together, where there may be varying capabilities to authenticate an entity as those identifiers.

Both of the above additional-identifier approaches are expected to have interoperable implementations for the concept of expressing an additional identifier that a verifier might be able to authenticate against a subject entity (whether it's a human across a desk or with a session in a web browser). (Note: Pending finalization of the ELM selection of identifier schemes, this feels like a placeholder and I haven't tracked down a hard answer as to whether urn:epass is really what they intend to use)

TL;DR: maybe the community could coordinate to use existing 'evidence' and various credentialSubject types to accomplish confidence method use cases, as some implementation communities are already doing, instead of reserving a new extension point in the VCDM. But I don't desire to be a blocker to other groups of implementers solving for these use cases in the way they prefer.

— Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/245#issuecomment-1633210047, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKLN3MC37QHRYR543VGIRM3XP4GE7ANCNFSM6AAAAAAZVNPP6I . You are receiving this because you authored the thread.Message ID: @.***>

-- Oliver Terbu Director Identity Standards, Spruce ID https://spruceid.com/credible

OR13 commented 12 months ago

The confirmation method (cnf) in IETF (RFC7800) is very close to what the original intention of confidenceMethod was.

...and is already understood by implementations of that RFC... making redoing the work at W3C CCG... pointless... unless the goal is to just create more semantic web vocabulary, and data integrity proof parallels, for every successful IETF work item, and a bunch of less successful ones (like JCS).... in which case, I look forward to seeing:

https://w3id.org/security#confidenceMethod ... compete with https://www.iana.org/assignments/jwt#cnf... in vc+ld+jwt, and possibly vc+ld+json assuming that JSON-LD desires strongly the ability to redo RFC7800 but with base58btc and w3id.org term definitions....

I'm elated this work has finally been adopted by the W3C CCG...

As soon as https://w3c-ccg.github.io/vc-confidence-method/ is no longer 404...

We can merge:

https://github.com/w3c/vc-data-model/pull/1142

In case it's not clear from my comment above, I don't think anyone serious about security should be (re-)doing this work, especially in a community group, but I am grateful that at least we won't be held up by lack of consensus on this topic in the vcwg.

... and I agree with everything @awoie said above, I wish the ccg best of luck improving on what is already possible.

msporny commented 12 months ago

I don't think anyone serious about security should be (re-)doing this work

Please do not cast aspersions or use personal attacks on others that choose to work on things that you disagree with.

As has been explained in the RWoT paper presentation, cnf is about proof of possession of a cryptographic key and only works in JWTs. This work item is different than cnf for at least the following reasons:

  1. It is about more than proof of possession of a cryptographic key (such as the using a physical identity document to raise confidence in the subject).
  2. It is agnostic to the securing mechanism and thus is re-usable across securing mechanisms.

I do think that @ottonomy makes a number of good points that the work item will need to take into account. That said, this is why we incubate work at the CCG; to work through the rough edges of pre-standards specifications.

brianorwhatever commented 12 months ago

@OR13 from RFC 7800

Other members of the "cnf" object may be defined because a proof-of-possession key may not be the only means of confirming the authenticity of the token.

Do you know of any other means being used in the wild?

msporny commented 11 months ago

@mprorock, @man4prez, @kwlinson -- Can you please provide a final determination on whether or not the Confidence Method Extension specification has been adopted by CCG?

This determination is blocking https://github.com/w3c/vc-data-model/pull/1142 in the VCWG.

This work item has met all of the work item adoption criteria, AFAICT.

man4prez commented 11 months ago

We approve this "W3C VCDM Confidence Method Extension" work item to be adopted by CCG.

@msporny Do you have an existing repo to transfer? Or do you need us to create a new repo?

msporny commented 11 months ago

We approve this "W3C VCDM Confidence Method Extension" work item to be adopted by CCG.

Excellent, thank you!

@msporny Do you have an existing repo to transfer? Or do you need us to create a new repo?

The repo to transfer is here... @awoie, you will have to initiate that transfer to w3c-ccg.

https://github.com/spruceid/confidence-method-spec

awoie commented 11 months ago

We approve this "W3C VCDM Confidence Method Extension" work item to be adopted by CCG.

Excellent, thank you!

@msporny Do you have an existing repo to transfer? Or do you need us to create a new repo?

The repo to transfer is here... @awoie, you will have to initiate that transfer to w3c-ccg.

https://github.com/spruceid/confidence-method-spec

I need permissions to transfer the repo to w3c-ccg. Getting this error:

You don’t have the permission to create public repositories on w3c-ccg

awoie commented 11 months ago

@mprorock @man4prez @brianorwhatever i transferred the repository to W3C CCG: https://github.com/w3c-ccg/confidence-method-spec

wip-abramson commented 5 months ago

Wondering if this issue should now be closed? Or is this work inprogress and this issue is tracking that?