Skip to content

Commit

Permalink
fix: anchors (#234)
Browse files Browse the repository at this point in the history 
Minor anchor fixes, noticed them on
https://github.com/uncefact/spec-untp/actions/runs/12259258110/job/34200984651#step:5:17
```
Warning:  Docusaurus found broken anchors!

Please check the pages of your site in the list below, and make sure you don't reference any anchor that does not exist.
Note: it's possible to ignore broken anchors with the 'onBrokenAnchors' Docusaurus configuration, and let the build pass.

Exhaustive list of all broken anchors found:
- Broken anchor on source page path = /spec-untp/docs/implementations/Registers:
   -> linking to #sample-register (resolved as: /spec-untp/docs/implementations/Registers#sample-register)
- Broken anchor on source page path = /spec-untp/docs/specification/DigitalIdentityAnchor:
   -> linking to #use-cases (resolved as: /spec-untp/docs/specification/DigitalIdentityAnchor#use-cases)
- Broken anchor on source page path = /spec-untp/docs/specification/VerifiableCredentials:
   -> linking to #vc-basic-profile (resolved as: /spec-untp/docs/specification/VerifiableCredentials#vc-basic-profile)

[SUCCESS] Generated static files in "build".
```

@onthebreeze, do we want to fail builds in case of broken anchors? It
will prevent PRs with broken anchors to be merged.

---------

Signed-off-by: Kseniya Shychko <[email protected]>
  • Loading branch information
@kshychko
kshychko authored Jan 6, 2025
1 parent 4fb77ce commit 66d9f89
Show file tree
Hide file tree
Showing 3 changed files with 5 additions and 5 deletions.
2 changes: 1 addition & 1 deletion website/docs/implementations/Registers.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ Register types are

|Register Name|Type|UNTP Scope|Geographic scope|Status|
|--|--|--|--|--|
|[Government of British Columbia Org Book](#sample-register)|Organisation|IDR, DIA|Canada|planned|
|[Government of British Columbia Org Book](#government-of-british-columbia-org-book)|Organisation|IDR, DIA|Canada|planned|


## Implementation Details
Expand Down
2 changes: 1 addition & 1 deletion website/docs/specification/DigitalIdentityAnchor.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -113,7 +113,7 @@ The registered identity class represents the registry member. For example, in a
* `name` is the human readable registered entity name and SHOULD match the registered name as it appears in the authoritative register.
* `registeredId` contains the simple identifier value that is unique within the register (but may not be globally unique) for example the VAT registration number.
* `idScheme` identifies the authoritative register. If the identity scheme is registered with UN/CEFACT then the `idScheme.id` MUST match the `identityRegister.id` in the UN/CEFACT scheme register.
* `registerType` is a coded value that allows verifiers to distinguish between different DIA [use cases](#use-cases)
* `registerType` is a coded value that allows verifiers to distinguish between different DIA [use cases](#dia-use-cases)
* `registrationScopeList` contains a list of URIs that define the scope of the member registration. The values are very specific to the register. For example a national business register would typically have a controlled vocabulary of entity types (eg [Australian Entity Types](https://abr.business.gov.au/Help/EntityTypeList))


Expand Down
6 changes: 3 additions & 3 deletions website/docs/specification/VerifiableCredentials.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -20,12 +20,12 @@ A key design principle that is applicable to decentralized ecosystems such as UN
| ID | Name | Requirement Statement | Solution Mapping |
| ----- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- |
| VC-01 | Integrity | VC technology recommendations must support tamper detection, issuer identity verification, and credential revocation so that verifiers can be confident of the integrity of UNTP credentials. | All VC options support this requirement |
| VC-02 | Compatibility | VC technology recommendations for issuing UNTP credentials should be as narrow as practical and should align with the most ubiquitous global technology choices so that technical interoperability is achieved with minimal cost | [Basic profile](#vc-basic-profile) |
| VC-02 | Compatibility | VC technology recommendations for issuing UNTP credentials should be as narrow as practical and should align with the most ubiquitous global technology choices so that technical interoperability is achieved with minimal cost | [Basic profile](#vcdm-profile) |
| VC-03 | Human readable | VC technology recommendations must support both human readable and machine readable credentials so that uptake in the supply chain is not blocked by actors with lower technical maturity. | [Render method](#render-method) |
| VC-04 | Discovery | VC technology recommendations must support the discovery and verification of credentials from product identifiers so that verifiers need not have any a-priori knowledge of or relationship to either the issuers or the subjects of credentials. | Presentations |
| VC-05 | Semantics | VC technology recommendations must support the use of standard web vocabularies so that data from multiple independent credentials can be meaningfully aggregated. | Vocabularies |
| VC-06 | Performance | VC technology recommendations should value performance so that graphs containing hundreds of credentials of any size can be traversed and verified efficiently. | [Basic profile](#vc-basic-profile) |
| VC-07 | Compliance | VC technology recommendations must meet any technology based regulatory requirements that apply in the countries in which credentials are issued or verified. | [Basic profile](#vc-basic-profile) |
| VC-06 | Performance | VC technology recommendations should value performance so that graphs containing hundreds of credentials of any size can be traversed and verified efficiently. | [Basic profile](#vcdm-profile) |
| VC-07 | Compliance | VC technology recommendations must meet any technology based regulatory requirements that apply in the countries in which credentials are issued or verified. | [Basic profile](#vcdm-profile) |
| VC-08 | Openness | VC DID method recommendations must not drive users towards closed ecosystems or proprietary ledgers so that there is no network effect coercion towards proprietary ledgers. | [DID methods](#did-methods) |
| VC-09 | Portability | VC DID method recommendations must allow users (issuers) to move their DID documents between different service providers so that long duration credentials can remain verifiable even when issuers change service providers. | [DID methods](#did-methods) |
| VC-10 | Evolution | VC technology is evolving and UNTP recommendations must evolve as newer tools and versions become ubiquitous | Roadmap |
Expand Down

0 comments on commit 66d9f89

Please sign in to comment.