Re: Modeling credentials issued by a proxy issuer

As usual, someone from BC has answered far better than I could have. What
John said is exactly what I was trying to say.

On Mon, Mar 23, 2020, 10:43 Jordan, John CITZ:EX <John.Jordan@gov.bc.ca>
wrote:

> Hi All … I should think this a typical “accreditation” pattern.
>
> By this I mean there is a body that maintain governance authority over the
> legitimate issuing of a credential. So there may be an authority on
> accredited universities and the types of credentials they may issue.
>
> This accreditation organization can run a “Credential Registry” that lists
> all accredited entities including their issuer DID for example… this allows
> machine discovery of DID. Of course the DID would be created by the
> accredited entity and added to their page in the credential registry via a
> trusted process.
>
> An example of a credential registry is our OrgBook BC service which list
> the authentic and authoritative data for all British Columbia legal
> entities. Right now there are no DIDs in there as we don’t yet have a
> trusted process to connect humans to legal entities and therefore grant
> them access to OrgBook BC to add their issuer DID .. but .. this is
> possible in time.
>
> So .. just seeing Brent’s comment re Trust Framework .. I am agreeing with
> that .. this is about knowing the trusted issuers, what are the credentials
> that are meaningful to a trust community/ecosystem and making that chain of
> trust discoverable both by humans via governance and digitally via a suite
> of capabilities including DIDs, VCs, credential registries, etc.
>
> This isn’t a problem that is solved within the VC data structure I don’t
> believe.
>
> You can read more about the concepts of the Trust over IP stack (tech and
> governance) here if you have IEEE Exploe …
> https://ieeexplore.ieee.org/document/9031548/keywords#keywords or here
> (and there are updates coming this week to the RFC)
> https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0289-toip-stack
>
> My thoughts anyways,
> J
>
>
>
> From: Isaac Patka <isaac@bloom.co>
> Date: Monday, March 23, 2020 at 9:25 AM
> To: "public-credentials@w3.org" <public-credentials@w3.org>, Anil Lewis <
> anillewi@ca.ibm.com>
> Subject: Re: Modeling credentials issued by a proxy issuer
> Resent-From: <public-credentials@w3.org>
> Resent-Date: Monday, March 23, 2020 at 9:23 AM
>
> Hi Anil,
>
> It depends on if the delegated issuer is responsible for managing the
> lifecycle of the credential. If the issuer is taking full responsibility
> for the credential, it may make sense to put the university/ employer
> inside of the credentialSubject as a data provider. If the university/
> employer is taking a more active role in managing the credentials, then
> they could be the issuer with the 3rd party acting as a custodian for the
> key.
>
> Isaac
> On Mar 23, 2020, 12:12 PM -0400, Anil Lewis <anillewi@ca.ibm.com>, wrote:
>
> Hi Dmitri,
> This use case is more for the clearing house of the worlds who issue
> credentials on behalf of other universities and employers trusts these 3rd
> parties. However, these 3rd parties when they issue the credential, want to
> make sure that when they issue these credentials, the holder understands
> that the 3rd party is doing it on behalf of the university and want that
> information conveyed in the verifiable credential. How can this be modeled
> in the current version of Verifiable credential. Note that this 3rd party
> has no access to any of the keys of the original issuers so the signature
> in the proof will belong to the 3rd party
>
>
>
> ________________________________
>
>
> Anil Lewis
> Senior Managing Consultant
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <Image.15849663741781.png>
>
>
>
>
>
>