Re: Credential Chaining

I am e.g working on an app that acts as Repository (Vault+Wallet) for VCs.
I am in charge of verifying to the minimum needs of the involved parties
and my best efforts, that the VCs stored in my vault are being accessed by
the rightful owner.

About using the registry, I think it is Optional and depends on how
compliant you want to be for both users and stakeholders. e.g.

validationThe assurance that a verifiable credential
<https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials> or a
verifiable
presentation
<https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations> meets
the needs of a verifier <https://www.w3.org/TR/vc-data-model/#dfn-verifier> and
other dependent stakeholders. This specification is constrained to verifying
<https://www.w3.org/TR/vc-data-model/#dfn-verify> verifiable credentials
<https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials> and
verifiable
presentations
<https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations> regardless
of their usage. Validating verifiable credentials
<https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials> or verifiable
presentations
<https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations> is
outside the scope of this specification.



https://www.w3.org/TR/vc-data-model/#dfn-verifier


[image: Screen Shot 2022-07-04 at 01.24.34.png]

--
Eduardo Chongkan



On Mon, Jul 4, 2022 at 1:20 AM Snorre Lothar von Gohren Edwin <
snorre@diwala.io> wrote:

> So the DID is an important piece here, but that has been exchanged so the
> issuer knows what to issue too. But this brings us into the which DID did I
> hold the certain credential on, and not going into that.
> User "connects" with the issuer with a DID. They can communicate and
> can wrap data around a did.
> Issuer wants to verify something before issuing. Sorry for using
> identifying and misleading the discussion.
> Issuer wants to verify that you are the rightful holder of a certain piece
> of information, a special credential(ticket to a festival), a value inside
> a certain credential(name, current place of residence is Denver) and so on.
> Holder tries to prove any of these set criterias with their credentials
> and issuer can verify that their criteria is met.
> OIDC solves this by using their centralized identifying mechanism because
> you log in.
> But credentials should be able to just have a ping pong and the issuer
> software have simple ways of setting up criterias for issuance.
>
> Why do we need a registry in the middle here?
>
> ᐧ
> ᐧ
>
> On Mon, Jul 4, 2022 at 8:40 AM Eduardo A. Chongkan Líos <
> e.chongkan@gmail.com> wrote:
>
>> I think it is not necessary to confirm the Identity of the person the
>> credential is being issued to, because it will be chained to a DID.
>>
>> Issues are the ones responsible for verifying the Identity, but that is
>> detached to the model.
>>
>> e.g. Upon Registry for a Test, a user needs to verify his identity PRIO
>> making the test. By the time the credential is issued by the Issuer, the
>> DID is already known and other confirmations have taken place. Like
>> Onboarding with AML
>>
>> verifiable data registryA role a system might perform by mediating the
>> creation and verification
>> <https://www.w3.org/TR/vc-imp-guide/#dfn-verify> of identifiers, keys,
>> and other relevant data, such as verifiable credential
>> <https://www.w3.org/TR/vc-imp-guide/#dfn-verifiable-credentials> schemas,
>> revocation registries, issuer public keys, and so on, which might be
>> required to use verifiable credentials
>> <https://www.w3.org/TR/vc-imp-guide/#dfn-verifiable-credentials>. Some
>> configurations might require correlatable identifiers for subjects
>> <https://www.w3.org/TR/vc-imp-guide/#dfn-subjects>. Some registries,
>> such as ones for UUIDs and public keys, might just act as namespaces for
>> identifiers.
>>
>> --
>> Eduardo Chongkan
>>
>>
>>
>> On Mon, Jul 4, 2022 at 12:32 AM Snorre Lothar von Gohren Edwin <
>> snorre@diwala.io> wrote:
>>
>>> Is this being thought of as too complicated?
>>> I assume that when someone wants to issue a credential to someone, there
>>> has to be an identifying step of some sorts.
>>> What we plan to try out is that the person who issues, has knowledge
>>> about something about the holder they are to issue to, if it is some
>>> important things.
>>> They can then set a criteria that the holder has to prove before the
>>> issuance happens. This might be out of any spec or anything.
>>> But the thought is that you read an issuance request, and to be able to
>>> accept it you have to prove that you hold a certain VC, "drivers license",
>>> and that matches their known value?
>>> Does anything have to be chained here? Or just a ping pong of
>>> credentials?
>>> ᐧ
>>>
>>> On Sun, Jul 3, 2022 at 11:39 PM Harrison <harrison@spokeo.com> wrote:
>>>
>>>> Just curious:  I can imagine that some Issuers would want to check the
>>>> authenticity of the Holder (i.e. making sure that the Holder is who they
>>>> say they are) before issuing a credential.  Otherwise, anyone can claim
>>>> that they are Tom Cruise and get his credentials.  What do we do in this
>>>> case?
>>>>
>>>> In this scenario, I can imagine that the Holder has a special,
>>>> "soulbound" (i.e. non-transferable), and secure-enclave-like credential
>>>> that includes authentication factor information like SMS OTP and/or hashed
>>>> biometric tokens, and then the Issuer can check against this special
>>>> authenticator credential before deciding whether to issue a credential to
>>>> the Holder or not (i.e. credential chaining).  This problem has probably
>>>> come up before, and does the high-level concept above make sense?  Or is
>>>> there a better alternative?
>>>>
>>>> Sincerely,
>>>> Harrison
>>>>
>>>>
>>>>
>>>> On Sat, Jul 2, 2022 at 12:31 PM Brent Shambaugh <
>>>> brent.shambaugh@gmail.com> wrote:
>>>>
>>>>> Thank you all. I believe this is what I had in mind. It is sort of
>>>>> like maintaining state with verifiable credentials. You cannot do this
>>>>> unless you've done this. Prerequisites. I'll chew on this like manna from
>>>>> heaven.
>>>>>
>>>>>
>>>>> -Brent Shambaugh
>>>>>
>>>>> GitHub: https://github.com/bshambaugh
>>>>> Website: http://bshambaugh.org/
>>>>> LinkedIN: https://www.linkedin.com/in/brent-shambaugh-9b91259
>>>>> Skype: brent.shambaugh
>>>>> Twitter: https://twitter.com/Brent_Shambaugh
>>>>> WebID: http://bshambaugh.org/foaf.rdf#me
>>>>>
>>>>>
>>>>> On Thu, Jun 30, 2022 at 3:43 AM David Chadwick <
>>>>> d.w.chadwick@truetrust.co.uk> wrote:
>>>>>
>>>>>> Yes. We have implemented this following the UK Power of Attorney
>>>>>> model, where one person (the attorney) can obtain the VC of another person
>>>>>> (the donor) who has become incapacitated. The attorney must possess a PoA
>>>>>> VC first and present it to the issuer of the donor's account.
>>>>>>
>>>>>> Kind regards
>>>>>>
>>>>>> David
>>>>>> On 29/06/2022 17:33, Brent Shambaugh wrote:
>>>>>>
>>>>>> Is there such a thing as credentials that can only be issued if the
>>>>>> holder already has a particular credential?
>>>>>>
>>>>>> --
>>>>>> -Brent Shambaugh
>>>>>>
>>>>>> GitHub: https://github.com/bshambaugh
>>>>>> Website: http://bshambaugh.org/
>>>>>> LinkedIN: https://www.linkedin.com/in/brent-shambaugh-9b91259
>>>>>> Skype: brent.shambaugh
>>>>>> Twitter: https://twitter.com/Brent_Shambaugh
>>>>>> WebID: http://bshambaugh.org/foaf.rdf#me
>>>>>>
>>>>>>
>>>
>>> --
>>>
>>> *Snorre Lothar von Gohren Edwin*
>>> Co-Founder & CTO, Diwala
>>> +47 411 611 94
>>> www.diwala.io
>>> <http://www.diwala.io/>
>>> *Stay on top of Diwala news on social media! **Facebook
>>> <https://www.facebook.com/diwalaorg>** / **LinkedIn
>>> <https://www.linkedin.com/company/diwala>** / **Instagram
>>> <https://www.instagram.com/diwala_/>** / **Twitter
>>> <https://twitter.com/Diwala>*
>>>
>>
>
> --
>
> *Snorre Lothar von Gohren Edwin*
> Co-Founder & CTO, Diwala
> +47 411 611 94
> www.diwala.io
> <http://www.diwala.io/>
> *Stay on top of Diwala news on social media! **Facebook
> <https://www.facebook.com/diwalaorg>** / **LinkedIn
> <https://www.linkedin.com/company/diwala>** / **Instagram
> <https://www.instagram.com/diwala_/>** / **Twitter
> <https://twitter.com/Diwala>*
>