diff --git a/text/0000-certification.md b/text/0000-certification.md index 7a1be06..9b92a8e 100644 --- a/text/0000-certification.md +++ b/text/0000-certification.md @@ -1,4 +1,4 @@ -- Feature Name: Certificate +- Feature Name: Grid Certification - Start Date: 10/12/21 - RFC PR: @@ -41,72 +41,138 @@ support the following actions: - Creating an audit request - Updating the status of a request -For the purpose of this RFC the factory actions will be excluded. +For the purpose of this RFC the factory audit request system will be excluded. + +Communicating Certification details via email, web portals, or traditional +methods creates uncertainty for sourcing teams accross the industry because +they lack a shared view of a certificates validity. Siloed views of certificate +data create difficulty when sourcing and validating factory certifications. +Hyperledger Grid Certification aims to address this challenge by providing a +mechanism for trade partners to collaborate on the creation and modification of +a purchase order, all while enjoying a shared view into the state of the order. + # Motivation [motivation]: #motivation -The Grid Certificate implementation is designed for sharing factory certification -data between participants. Certification is a common concept within supply chains -and could naturally be extended to the product level. +The Grid Certification implementation is designed for sharing factory +certification data between industry participants. The validation of factory +level certifications is pain point retailers share accross the industry. This +communication of certificate information occurs in various ways today: by +phone, email, SMS, websites, etc. The primary pain point includes the discovery +and verification of the certification claims for a given factory. In practice, +each brand and retailer ends up independently verifying these claims with the +certifying body that performed the original audit. This process is +time-consuming, expensive, and error prone. Discrepancies between systems +result in costs related to administrative time, product recalls, and more. + +The Grid Factory certification concept aims to address these pain points by +offering a common industry solution for sharing factory certification +information between participants on Grid. Trade partners have the option to +integrate this Grid component with existing systems of record. + +Expected outcomes include: + +- Improved cost efficiency. An organization’s financial results can benefit +from a reduction in administrative time spent manually validating factories +certifications authenticity. + +- Improved transaction accuracy. Automated sharing of factory certification +data can reduce errors that stem from manual data entry. + +- Increased speed. Changes in a factories certification status can be quickly +communicated between organizations, leading to faster response times, improved +sourcing decisions and production planning, greater customer satisfaction, and +visibility into factory information. + +- Improved productivity. Less time spent comparing documents and resolving +discrepancies means team members can focus on move value-add business +opportunities. The design will address use cases including: -- Sharing of factories, certificates, and standards data across a network +- Sharing of factories, certificates, and standards data on grid - Enriching a UX experience that models the real-world workflow of issuing certs It is also useful to use certification data as auxiliary data in other supply -chain solutions. For example, in track and trace, the location of a factory can -be extended to include the certificates the factory holds. When presenting this -information later to a sourcing specialist, it makes its easier for them to vet -potential factories. Certifications can also be extended to the product level. -Therefore, certificates becomes a reusable and important component within Grid. +chain solutions. For example, in track and trace smart contract, the location +of a particular factory in a supply chain can be extended to include the +certificates the factory holds. When presenting this information later to a +sourcing specialist, it makes its easier for them to vet potential factories. +This workflow will introduce a certificate data model that could also be +extended to include product level certifications. # Guide-Level Explanation [guide-level-explanation]: #guide-level-explanation -A certification is a business transactions that specifies the details of a factories -capabilities. The transaction contains information such as the when the certificate -was issued, what the certificate is for, and when the certificate expires. +A certification is a business transaction that specifies the details of a +factories capabilities. The transaction contains information such as the when +the certificate was issued, what the certificate is for, and when the +certificate expires. -In the simplest business scenario, a standards body creates a standard, then the -standards body accredits a certifying body. Now that accredited certifying body -can go and audit a factory offline, then issue a certificate to that factory for -all to see on the Splinter network. In more complex business scenarios, a factory -can request to be audited, manage the status of their request, and profile data. +In the simplest business scenario, a standards body creates a standard, then +the standards body accredits a certifying body. Now that accredited certifying +body can go and audit a factory offline, then issue a certificate to that +factory for all to see on the Splinter network. In more complex business +scenarios, a factory can request to be audited, manage the status of their +request, and profile data. ## Entities +We will need to define `PermissionAlias`'s for standards bodies, certification bodies, factories. + +Standards body: +``` +let alias = PermissionAlias { + name: “certificate.standard_body”.to_string(), + permissions: vec![“create_standard”.to_string(), “update_standard_version”.to_string(), “accredit_cert_body”.to_string() ], + transitions: vec![“confirmed”.to_string()] +} +``` + +Certification body: +``` +let alias = PermissionAlias { + name: “certificate.cert_body”.to_string(), + permissions: vec![“issue_certification”.to_string(), “update_certification”.to_string()], + transitions: vec![“confirmed”.to_string()] +} +``` + +Factories +``` +let alias = PermissionAlias { + name: “certificate.factory”.to_string(), + permissions: vec![create_factory.to_string(), update_factory.to_string()], + transitions: vec![“confirmed”.to_string()] +} +``` + ## Actions This design introduces four smart contract actions that, with the appropriate permissions, a user of the system may perform. An action represents a change to the shared state of a certification. +- Create factory. Allows for the creations of a new factory +- Update factory. Allows for the modification of an existing factory profile - Create standard. Allows for the creation of a new standard. -- Update standard. Allows for the modification of an existing standard. This will -create a new version of the same standard. -- Accredit certifying body. Allows a certifying body to issue certificates for a -given standard. +- Update standard. Allows for the modification of an existing standard. This +will create a new version of the same standard. +- Accredit certifying body. Allows a certifying body to issue certificates for +a given standard. - Issue certificate. Allows a certifying body to issue a certificate to a factory. - ## Transactions - ## Permissions - # Reference-level explanation [reference-level-explanation]: #reference-level-explanation ## State -### Certificate Representation - -### Defined GS1 Properties - # Drawbacks [drawbacks]: #drawbacks @@ -115,11 +181,10 @@ given standard. [alternatives]: #alternatives - - # Prior Art [prior-art]: #prior-art - +- [Grid Workflow RFC](https://github.com/hyperledger/grid-rfcs/pull/24) +- [Grid Identity RFC](https://github.com/hyperledger/grid-rfcs/pull/23) # Unresolved questions [unresolved]: #unresolved-questions