Discuss Identity Anchoring Credential Data Model

[ashleythedeveloper]

In our UNTP meetings and through my discussions in related projects, it has become clear we need identity anchoring credentials.

This ticket aims to determine if we should develop a new data model for identity credentials or if the existing Conformity Credential model will suffice.

[PatStLouis]

What would you see as an Identity Anchoring Credential? Would a business registration VC fit this category for an organization's identity credential? If so, my current train of thought is do provide this as a conformityCredential with a governance.compliance topic. It would say here's the proof that I'm a legal entity and here's my legal identifier provided by my jurisdiction.

What is the goal of the Identity Anchoring Credential discussed? (I was not part of meetings but will start to attend in the following weeks)

Is it related to trust? Would trust registries be related to this?

[swcurran]

We’ve been discussing this in the extended BC Team and @onthebreeze suggested we look at doing a PR into the Identifiers section about the concept of an Identity Anchoring Credential. I think it is a bit premature to do a PR, but have done a bit of thinking about it and have these ideas. I’m far from a Registries expert (although I have been working with BC Registries for a while), so others with greater experience are encouraged to weigh in on this one.

• An Identity Anchoring Credential should be resolvable for at least all verifiable credential issuers in the ecosystem.
• Whatever identifier that can be used to identify the issuer of a verifiable credential must be one element of the credential. For the most part that is a DID. In UNTP, can it ONLY be a DID, or do we have to make it more generic/flexible (e.g. URI)?
• What else should the schema of the credential include?
  • We should definitely canvas for prior work in this area. The DID is novel in this effort (a self-created identifier — not one assigned to the entity), but legal entities are assigned many identifiers by many authorities. And I’m sure that other groups working on parallel initiatives are investigating binding a DID to a legal entity.
  • In addition to the DID, the credential has to include some other identifiers about the legal entity, but how far do we go?
  • I think the Legal Name MUST be included.
  • An example of other possible information. This is what is in OrgBook BC about Hudbay Minerals Inc., and this is what GLEIF says about Hudbay. Its home registration is the Government of Canada Registry (presumably there is a link to that somewhere). An entity may have other well-known identifiers (S&P, D&B, etc.) as well. There is a lot of complexity here. I suspect we need the ability to include several identifiers, and for each, there should probably be the identifier, a URL to the registration of that identifier (if any -- or should it be dynamically resolvable), and the registering jurisdiction (government) or entity (industry).
    • Is there a vocab for this already?
  • It could (but I don't think it should) include additional registration information (dates, entity types, addresses, etc.). Date of creation perhaps, but I think we would want to avoid frequently changing dates (expiry, last updated, etc.). Of course by definition a date of issuance of the Identity Anchoring Credential itself would be included (per the VCDM).
  • Revocation support required? Optional?
  • I think there should be some sort of "Level of Assurance" as to the identity proofing done by the Issuer of the Identity Anchoring Credential. That in turn requires governance, and the Identity Credential issuer publishing their Governance Framework. A claim in the verifiable credential that is a link to the governance framework for the level of assurance done is appropriate.
• While Identity Anchoring Credentials are needed about legal entities, In the context of the UNTP, they are also requird about Governments issuers. I'm not certain, but I suspect that is novel work -- Governments having DIDs, and some "authority" attesting to the binding of those DIDs to the issuing jurisdiction. Further, Governments will not have a single DID for the entire government, but likely a hierarchy of issuers -- perhaps leading to the UN. This may even get into legislation for some jurisdictions.
• Trust Registries fit in this model, where a Trust Registry is the issuer of the Identity Anchoring Credential, as well as holding a human/API searchable registry of members.

I also think that this new credential type needs to be covered in the Architecture section of the UNTP -- which also means updating the beautiful pictures. OK to leave that off for now, but I think it will ultimately be needed.

[onthebreeze]

First draft is here https://jargon.sh/user/unece/DigitalIdentityAnchor/v/working/artefacts/readme/render

[onthebreeze]

PR for first draft of DIA here https://github.com/uncefact/spec-untp/pull/200

[onthebreeze]

Slack channel discussion about that first draft :

Dr. Susanne Guth-Orlowski Yesterday at 8:08 PM https://oid.spherity.com/

oid.spherity.comoid.spherity.com Vocabularies | OID Data Model OID

8:08 Please check this out. 8:10 https://github.com/EWC-consortium/eudi-wallet-rulebooks-and-schemas/blob/main/rulebooks/rb001-legal-person-identification-data.md

rb001-legal-person-identification-data.md Legal Person Identification Data (LPID) Rulebook 5 September 2024 updated 17 September 2024 Table of Contents • 1 Introduction
• 1.1 Scope
• 1.2 Background
• 1.3 Goal of the LPID attestation
• 1.4 Key words
Show more https://github.com/EWC-consortium/eudi-wallet-rulebooks-and-schemas|EWC-consortium/eudi-wallet-rulebooks-and-schemasEWC-consortium/eudi-wallet-rulebooks-and-schemas | Added by GitHub

steve.capell Yesterday at 8:15 PM That’s the EU personal wallet ID. Don’t think we want to touch personal data in UNTP. But even if we did, that would just be another identity register 8:16 The UNTP DIA is not an identity scheme, it’s a way to map self-sovereign identifiers (eg DIDs) to authoritative registered identifiers (eg VAT registration numbers)

Dr. Susanne Guth-Orlowski Yesterday at 8:45 PM Hi Steve, it's for Legal Persons. The EUDI project, also does specs for the company identity, and I think it would be good if we relate our work ot what is done there. I think we need an extra meeting for solely discussing these concepts.

Nis Jespersen Yesterday at 9:38 PM Great work, @steve.capell ! I left you a bunch of comments and change requests.

steve.capell Today at 12:37 AM Hi Nis - thanks for all the comments. Will work through them. Let’s discuss the last point about how to protect from malicious actors issuing DIAs when they aren’t the actual registry operator 12:39 My thinking on this is that the UN register of schemes (which isn’t implemented yet but will be described in the identity resolver section) is essentially a trust list because it’ll list the did:web of the authoritative registers 12:40 Essentially the list is the global whitelist. If not on the list then it’s up to the verifier to know the valid registrar issuer DID. 12:45 Also this one “I suggest we switch it around. Subject id is the DID. This is what verifiers are interested in, so let's not add "proprietary" paths to get to it. Add whatever registration URLs in an array. That part is less essential.” 12:48 From the perspective of the registrar, the subject should be the registered member ID, not their DID. It’s basically a statement from a registrar that a member has proven ownership of one or more DIDs. Not the other way around. If it were the Australian business register the DIA would be an attestation from the Australian tax office (DIA issuer) that ABN 123456 (subject) has proven ownership of DID abcdxyz (edited)

Nis Jespersen Today at 1:20 AM On the malicious actors issuing DIAs part: Agreed, that’s what I was sort of thinking too, the UNTP website playing a role. :+1: 1

steve.capell Today at 1:21 AM @Susanne

• that natural person / company certificate stuff at https://oid.spherity.com/eucc is interesting. There’s no conflict with DIA because it’s a specification for representation of a company register entry whilst DIA is just ID linking

oid.spherity.comoid.spherity.com EU Company Certificate | OID Data Model 1 Abstract

Nis Jespersen Today at 1:22 AM On the second point, seems like we just have different perspectives on who’s the primary data consumer. Certainly not a hill I’m willing to die on. :slightly_smiling_face:

steve.capell Today at 1:23 AM Not sure whether there is overlap with the chained credential part. It is true that the purpose of DIA is to facilitate trust chains that end at trusted “anchors” 1:25 Ok thanks Nis - I agree it’s not clear enough that the key to integrity is having a whitelist of trust anchor DIDs. I’ll add stuff about that

Patrick St-Louis Today at 4:00 AM @nis

@steve.capell I will be working on DIA for BCGov in the coming months. Our goal is to bind a business registration to a did they control. There's a few considerations we identified in our preliminary evaluation of the feature: The need to prevent the business from providing a did they do not control The need to ensure the request comes from a legitimate person authorized to request a DIA on behalf of their company The need for this DIA to be discoverable With this in mind, we will have the following pattern: Request a Digital Business Card presentation from the entity requesting DIA (DBC is an existing work item within BCGov) Once authorized, request a DID auth from the DID they wish to bind to their organization Once bound, we will issue and make this DIA discoverable in Orgbook, same as with our Conformity Credentials From this point on, this organization can take this VC and host it at another location, or have a service in their did doc point directly at the hosted resource in Orgbook. We will also strongly encourage the use of the whois linked-vp service: https://identity.foundation/trustdidweb/#whois-linkedvp-service 4:03 I would strongly encourage, for the DIA, to have the subject's DID as the credentialSubject.id

Patrick St-Louis Today at 4:32 AM just finished my first round of review, overall I like the approach here, besides the verifiedDIDList which I'm not too convinced by yet. As echoed by one of the comments, credentialSubject.id should be where the did goes. Our approach seems aligned with this PR. :+1: 1

steve.capell Today at 6:21 AM I’m not too bothered whether it’s a list of DIDs in one credential or whether it’s a separate credential for each linked DID - but I can certainly see that a given business may want / need to link more that one DID to their registered ID- right? (edited)

steve.capell Today at 6:26 AM Both you and Nis want to see the linked did as the subject ID rather than the registered business ID. so long as we get rid of the list and the DIA becomes a 1:1 relationship then it doesn’t matter as much. But it does feel backwards to me. The DIA is a statement from a register about one of their members “the party we know as BC business 12345 has proven control of DID abcxyz and has this list of scopes / roles”. So it’s a declaration about the registered business, not about the businesses DID. 6:28 Again, if 1:1 it doesn’t matter so much but I just would like to understand why you think the subject ID should be the DID?

steve.capell Today at 6:54 AM This is a great discussion btw - thanks to @Susanne and @nis and @Patrick St-Louis for taking the time to do a detailed review and suggesting these changes. Exactly how consensus driven standards development should work. ;) 6:55 I’ll copy this discussion to a ticket so that we don’t lose it

Patrick St-Louis Today at 7:42 AM To put into context, when we issue a DCC, we identify the entity related to the DCC by using the issuedToParty , which currently looks something like this: "issuedToParty": { "id": "https://orgbook.gov.bc.ca/entity/A0131571" "name": "PACIFIC CANBRIAM ENERGY LIMITED", "registeredId": "A0131571" } While this enables us to identify an entity linked to the DCC, it doesn't enable them to make statements about it. To do so, we need a DIA. We are planning to have a DIA which looks something like: "credentialSubject": { "id": "did:web:example.com:pacific-canbriam" "name": "PACIFIC CANBRIAM ENERGY LIMITED", "registeredId": "A0131571" } The goal here is for the entity to prove their did is bound to their registeredId, enabling them to include the DCC in some presentations and so on. I think the benefit of having a credentialSubject.id be the did, is that this is a vetted mechanism and well known principle, that when you have a presentation.holder, this should match the credentialSubject.id of the VC contained within the presentation. This is also a requirement for a linked-vp to be effective. https://identity.foundation/linked-vp/#example-linked-verifiable-presentation-resource 7:45 One solution that might be an in-between having multiple did and using the credentialSubject.id, would be to have the DIA contain multiple credentialSubject : "credentialSubject": [{ "id": "did:web:example.com:pacific-canbriam" "name": "PACIFIC CANBRIAM ENERGY LIMITED", "registeredId": "A0131571" },{ "id": "did:web:some-other-did.example" "name": "PACIFIC CANBRIAM ENERGY LIMITED", "registeredId": "A0131571" }] This is just another suggestion to consider

[onthebreeze]

Another useful discussion on signal:

@Patrick St-Louis - regarding verifiedDidList in the DIA , is it the “List” part that you object to? Ie you want to limit to one linked DID per credential? 6:17 am

BB

Bree Blazicevic Sorry my laptop out of juice! Will be back online shortly! 6:57 am

Patrick St-Louis a few things, I think the list part is a new concept, as with having the id as the did is a very common vc concept. Usually you want the holder of a presentation be the subject of the credentials it presents

I want to say one did per DIA credential would be best but I'm not sure

The issue I have with the list is what is the process to add/remove dids from there?

it sounds like you are bound to 1 DIA issuer and will need to create a did auth for all the dids individually

I feel it would create an odd process, but I might be wrong

What would maybe make sense is for a holder to have a presentation holding all their DIA 7:07 am

Ok - im good with getting rid of the list. If a business controls multiple DIDs and they want to link more than one then they can get a DIA per DID Edited7:09 am

Patrick St-Louis I would say maybe some exploration about which situations might warrant them multiple dids across different use cases

I can see why it can be useful by concept, but I don't have a specific use case coming to mind

As far as our partners will be in bcgov, I would even go as far to say as most of them don't even have 1 did currently 7:11 am

I can think of a few cases where a business needs to link more than one did. But I realise that they are all better served with separate DIAs anyway - so I’m also convinced to drop the list 7:12 am

Patrick St-Louis One use case I can think is if a business is registered into 2 jurisdiction, and 1 of the jurisdiction mandates a specific did service provider for some reason, but even then, they would need the 2 jurisdiction to issue their own DIA

I think the multiple known DID problem can be solved by using the 'alsoKnownAs' feature of the did core spec

and each individual 'alsoKnownAs' DIDs would link to their own DIA ? 7:14 am

One is just a change of did service provider - but a need to maintain the historical link because of existing issues credentials 7:15 am

Patrick St-Louis So more of a "previouslyKnownDIDs" use, thats a valid use case 7:16 am

Another is so a business can use DIDs internally for more fine grained authorisation - so different officers control different DIDs for different purposes - but all in the same registered business 7:16 am

Patrick St-Louis theres an issue that if they change service provider, and the old did document isn't available, the credential won't be verifiable regardless, unless theres some sort of portability mechanism

tdw sort of addresses this but the feature still needs to be vetted for

I think this second use case is probably a more valid reason to support it

I will reflect on it 7:18 am

That’s true - but business can choose to keep subscription to old provider for a suitable transition period

In any case, I suspect these use cases are arguments in favour of multiple DIAs rather than one DIA with changing list. 7:20 am

BB

Bree Blazicevic You Another is so a business can use DIDs internally for more fine grained authorisation - so different officers control different DIDs for different purposes - but all in the same registered business

this might be key for a business that runs different operations globally, so one DID per region (site) and what about function - so Finance may require a separate DID that operates in value exchanges vs supply chain data

[onthebreeze]

So - in summary I think we agree

1. There are genuine use cases where a business may want to link multiple DIDs to a registeredID
2. But these are equally of not better handled with multiple DIAs than a single DIA with a changing list of DIDs.
3. So we'll drop the verifiedDIDList property in favour of a single linked DID
4. The VC community would typically expect the linked DID rather than the registeredID to be the credentialSubject.id so we'll accept that.

Those are probably the most important proposed changes - since we agree on all that, will update the PR accordingly.

[onthebreeze]

ok, PR #200 has been updated with feedback accepted. I'm sure it's still not perfect but hopefully good enough to merge as a new baseline