Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add rules for contractor credential objects #51

Merged
merged 3 commits into from
Sep 6, 2024

Conversation

WadeBarnes
Copy link
Member

- Details can be found in bcgov/DITP#95

Signed-off-by: Wade Barnes <[email protected]>
Comment on lines 2 to 3
<CDT DID TBD>,Cyber Security and Digital Trust
<CSB DID TBD>,Court Services Branch
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CDT and CSB DIDs to be defined as part of bcgov/DITP#95

@@ -0,0 +1,2 @@
author_did,schema_name,version,details
<CDT DID TBD>,contractor-credential,1.0,https://github.com/bcgov/digital-trust-toolkit/blob/contractor-credential/docs/governance/employment/contractor-credential/governance.md#261-schema-definition
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question for @Gavinok or @esune,
Does the details field support arbitrary text, such as the reference URL I've specified here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the details field is free text - I forget how long it can be though.

@esune
Copy link
Member

esune commented Sep 5, 2024

Should we create generic wildcards for dev, without specifying specific DIDs? This would help us with onboarding any new development team without having to vet them first, since this environment is likely going to be the first proving ground.

@WadeBarnes
Copy link
Member Author

WadeBarnes commented Sep 6, 2024

When onboarding a new agent (team) with the endorser we have to register the agent with the endorser in one of two ways since we don't, and should never, allow open endorsement to all:

  • configure the per-connection settings for auto-endorsement.
  • register a set of rules for the new agent.

The first method is hidden and includes some manual/scripted steps. The second method is openly visible, descriptive, and has the added benefit of the history in git.

My preference moving forward is to onboard teams by registering their DIDs, and then we can decide to provide them with open (wildcard) or more restricted access to write schemas and cred defs.

I've purposely added some restrictions to both CDT and CSB rules. CDT, simply because this is the first time we're creating a DID for ourselves and I'd like to record our use cases as we evolve them. We have full control so it's easy for us to update our own rules. For this use case we've defined governance rules defining the rules and responsibilities of each party, the rules defined in this PR reflect those defined by the governance documentation and explicitly reflect the fact that CDT is responsible for issuing the schema and CSB is responsible for issuing the cred-def based on that schema. Adding the wild card to the version(s) allows the cred-def and schema to evolve without restriction.

Further having some rules defined on our own DID (CDT) forces us to make conscious decisions about what we're using it for so we can make better decisions.

@WadeBarnes WadeBarnes marked this pull request as ready for review September 6, 2024 18:16
@WadeBarnes WadeBarnes merged commit ae35359 into bcgov:main Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants