Need to scope objects of conformity

[trbouma]

Please review this table

https://github.com/CIOSC/CAS-Digital-Credentials/blob/main/scheme/objects/objca-table.md

We need to scope a subset that for DRAFT and which could go to PILOT stage (see at the link above)/ The template had been streamlined to 3 Parts. You can see drafts for Issuer and Digital Credentials. These are still very much a work in progress.

[kjansa]

Suggested object of conformity: Digital technology that issues digital credentials
Suggested object of conformity: Digital technology that stores and presents digital credentials

[brianorwhatever]

I propose breaking "Digital Trust Service" into 3 parts:

• Issuer Service (same as @kjansa suggestion above)
• Holder Service
• Verifier Service

These might be associated with the "Issuer", "Verifier" and "Holder" entity objects already in place?

[trbouma]

Add Presentation Service?

[brianorwhatever]

Add Presentation Service?

I would include that with holder service

[trbouma]

Thanks @brianorwhatever ! I will take a crack at revising

[trbouma]

OK - this is what I did: I created/modified:
Issuer Role, Holder Role, Verifier Role definitions, which refer to the actors. I created Issuer, Holder, and Verifier definitions that refer to the actual components.
I thought I could combine them, but they are very different things.

[kjansa]

@brianorwhatever - would you have a defintion for Issuer Service, Holder Service, and Verifier Service? Would it begin with "information technology that ..."?

[trbouma]

Add Credential Binding as an object of conformity. This would cover binding to holders via biometrics or device based authenticators.

[neiljthomson]

Possibly a bit off topic - I believe there are missing actors, actions and roles:

The term "Issuer" is used to define an actor/agent/service that "issues" a "verifiable" "credential" (VC) after "Know Your (thing)" processing is complete. However, "identifiers" (personal attribute composite key) and "assigned identifiers" (arbitrary GUIDs) are also created and provided (issued) to a Holder in order for the Holder to have an identifier which one or more VCs can be bound to. Implicit in the actions of a Verifier is verifying VCs and potentially identifier(s).

The current terms/vocabulary and 100-3 don't appear to acknowledge the creation process of "identifiers" or "assigned identifiers", nor the role of the actor/agent that generates those, nor the process of requesting and granting those identifiers to a Holder.

[trbouma]

Hi @neiljthomson - In our initial draft, we took a management systems approach (a la 17021) but were redirected by SCC to take a more product-oriented approach (17065). Thus the definitions are being reworked to reflect what the statement of work is looking for. To your points, I have tried to disambiguate by adding Issuer Role, Holder Role, Verifier Role,(actors) versus Issuer, Holder, Verifier (technical components). I also added decentralized identifiers and assigned identifiers.

[trbouma]

The latest set of definitions is here

[kjansa]

The subject of the draft requirements sentences reflect the Issuer (management) vs the product (credential, wallet, etc.) Requirements can be rewritten to reflect the Issuer Service (i.e. the technology, the credential) vs. the Org (Issuer). An example: "6.4.2 The Issuer shall ensure that the credential identifies the Issuer." can be rewritten to read: "6.4.2 The digital credential shall identify the Issuer."

[trbouma]

I will be be revising digital credentials based on a debate I had with the JSON-LD folks on Twitter. Result here. https://twitter.com/trbouma/status/1589212416310931459?s=61&t=LYMnbXKqmdIRVqQWbnEqeQ

You can find the debate in my earlier replies