diff --git a/README.md b/README.md index 969c46f..4d3d0e6 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,11 @@ # Identity And Trust Specifications This repository contains normative documents defining protocols and flows withing the Identity and Trust system to be -used in Catena-X. - -It does not specify any implementations, not does it contain any, it is simply to be understood as the reference point -for every future implementor. +used in Tractus-X projects. There are [designated editors](./pr_etiquette.md#the-designated-editors-as-of-sept-21-2023), who are the primary contributors to the content of this repository. Please file all change-requests through GitHub Discussions or Issues. For any contributions beyond that, please notice our [PR etiquette](pr_etiquette.md). -> This repository is intended to contain documents and graphs in an easily versionable format. We prefer Markdown and -> PlantUML over `*.docx`, `*.ppt` and `*.pdf`. \ No newline at end of file + diff --git a/pr_etiquette.md b/pr_etiquette.md index c0f4251..5d24d9f 100644 --- a/pr_etiquette.md +++ b/pr_etiquette.md @@ -59,7 +59,8 @@ Submitting pull requests in EDC should be done while adhering to a couple of sim - Jim Marino (@jimmarino) -## Responsible committers (as of Sept 21, 2023) +## Responsible committers (as of Feb 26, 2024) - Paul Latzelsperger (@paullatzelsperger) - Enrico Risa (@wolf4ood) +- Jim Marino (@jimmarino) diff --git a/specifications/M1/auth.flow.png b/specifications/auth.flow.png similarity index 100% rename from specifications/M1/auth.flow.png rename to specifications/auth.flow.png diff --git a/specifications/M1/auth.flow.puml b/specifications/auth.flow.puml similarity index 100% rename from specifications/M1/auth.flow.puml rename to specifications/auth.flow.puml diff --git a/specifications/M1/context.json b/specifications/context.json similarity index 100% rename from specifications/M1/context.json rename to specifications/context.json diff --git a/specifications/M1/credential.issuance.protocol.md b/specifications/credential.issuance.protocol.md similarity index 95% rename from specifications/M1/credential.issuance.protocol.md rename to specifications/credential.issuance.protocol.md index 1b2502f..2ed2c77 100644 --- a/specifications/M1/credential.issuance.protocol.md +++ b/specifications/credential.issuance.protocol.md @@ -4,8 +4,8 @@ This specification defines a protocol for Verifiable Credential (VC) issuance. S Protocol (CIP) defines the endpoints and message types for requesting credentials to be issued from a `Credential Issuer.` -This specification relies on the [Base Identity Protocol](./identity.protocol.base.md) and -the [Verifiable Presentation Protocol](./verifiable.presentation.protocol.md). +This specification relies on the [Base Identity Protocol](identity.protocol.base.md) and +the [Verifiable Presentation Protocol](verifiable.presentation.protocol.md). ## 1.1. Motivation @@ -27,11 +27,11 @@ associated with manual workflows that are best modelled using asynchronous messa # 2. Overview The Credential Issuance Protocol is designed to be used in conjunction with -the [Base Identity Protocol](./identity.protocol.base.md) and the -[Verifiable Presentation Protocol](./verifiable.presentation.protocol.md). This issuance interaction flow is expressed +the [Base Identity Protocol](identity.protocol.base.md) and the +[Verifiable Presentation Protocol](verifiable.presentation.protocol.md). This issuance interaction flow is expressed in the following diagram: -![Issuance Flow](./issuance.flow.png) +![Issuance Flow](issuance.flow.png) In the above sequence, the client uses the `Base Identity Protocol` to create a Self-Issued Identity token that it includes in its request to the `Credential Issuer.` If the VC request is approved by the `Credential Issuer`, a VC will @@ -62,16 +62,16 @@ the issuer. The request MUST include an ID Token in the HTTP `Authorization` header prefixed with `Bearer` as defined in -the [Base Identity Protocol Specification](./identity.protocol.base.md#411-vp-access-token). The `issuer` claim can be +the [Base Identity Protocol Specification](identity.protocol.base.md#411-vp-access-token). The `issuer` claim can be used by the Credential Issuer to resolve the client's DID to obtain cryptographic material for validation and credential binding. The ID Token MUST contain a `access_token` claim that is a bearer token granting write privileges for the requested VCs into the client's `Credential Service` as defined by -the [Verifiable Presentation Protocol specification](./verifiable.presentation.protocol.md) +the [Verifiable Presentation Protocol specification](verifiable.presentation.protocol.md) The ID Token MAY contain an `access_token` claim as defined in -the [Base Identity Protocol Specification](./identity.protocol.base.md) claim that can be used by the issuer to resolve +the [Base Identity Protocol Specification](identity.protocol.base.md) claim that can be used by the issuer to resolve Verifiable Presentations (VP) the client is required to hold for issuance of the requested VCs. If the issuer supports a pre-authorization code flow, the client must use the `pre-authorized_code` claim in the ID @@ -119,7 +119,7 @@ The issuer MAY respond with `401 Not Authorized` if the request is unauthorized an exception. If the VC request is approved, the issuer will respond with a write-request to the client's `Credential Service` using -the Storage API defined in the [Verifiable Presentation Protocol](./verifiable.presentation.protocol.md#5-storage-api). +the Storage API defined in the [Verifiable Presentation Protocol](verifiable.presentation.protocol.md#5-storage-api). # 4. Credential Offer Flow diff --git a/specifications/M1/diagram.styles.puml b/specifications/diagram.styles.puml similarity index 100% rename from specifications/M1/diagram.styles.puml rename to specifications/diagram.styles.puml diff --git a/specifications/M1/dsp.profile.md b/specifications/dsp.profile.md similarity index 100% rename from specifications/M1/dsp.profile.md rename to specifications/dsp.profile.md diff --git a/specifications/M1/identity-trust-sts-api.yaml b/specifications/identity-trust-sts-api.yaml similarity index 100% rename from specifications/M1/identity-trust-sts-api.yaml rename to specifications/identity-trust-sts-api.yaml diff --git a/specifications/M1/identity.protocol.base.md b/specifications/identity.protocol.base.md similarity index 99% rename from specifications/M1/identity.protocol.base.md rename to specifications/identity.protocol.base.md index 529140e..255347c 100644 --- a/specifications/M1/identity.protocol.base.md +++ b/specifications/identity.protocol.base.md @@ -112,7 +112,7 @@ list of space-delimited scopes the `access_token` claim will be enabled for. If present, the `access_token` claim MUST not be included. > A non-normative OpenAPI spec of an STS implementing client credentials flow is -> provided [here](./identity-trust-sts-api.yaml) +> provided [here](identity-trust-sts-api.yaml) # 7. The Identity and Trust Protocol Context diff --git a/specifications/M1/issuance.flow.png b/specifications/issuance.flow.png similarity index 100% rename from specifications/M1/issuance.flow.png rename to specifications/issuance.flow.png diff --git a/specifications/M1/issuance.flow.puml b/specifications/issuance.flow.puml similarity index 100% rename from specifications/M1/issuance.flow.puml rename to specifications/issuance.flow.puml diff --git a/specifications/M1/tx.dataspace.topology.md b/specifications/tx.dataspace.topology.md similarity index 100% rename from specifications/M1/tx.dataspace.topology.md rename to specifications/tx.dataspace.topology.md diff --git a/specifications/M1/verifiable.presentation.protocol.md b/specifications/verifiable.presentation.protocol.md similarity index 98% rename from specifications/M1/verifiable.presentation.protocol.md rename to specifications/verifiable.presentation.protocol.md index d3d6d01..5f1aa79 100644 --- a/specifications/M1/verifiable.presentation.protocol.md +++ b/specifications/verifiable.presentation.protocol.md @@ -116,7 +116,7 @@ including requiring the requester to present its own VPs. Implementations that support access control require an access token. To provide the opportunity for `Credential Service` implementations to enforce proof-of-possession, the access token MUST be contained in the `access_token` claim of a self-issued identity token as defined -in [Base Identity Protocol Section 4](./identity.protocol.base.md#4-self-issued-id-tokens). The self-issued token MUST +in [Base Identity Protocol Section 4](identity.protocol.base.md#4-self-issued-id-tokens). The self-issued token MUST be submitted in the HTTP `Authorization` header prefixed with `Bearer` of the request. # 4. Resolution API @@ -148,7 +148,7 @@ The following are non-normative examples of the JSON body: ```json { "@context": [ - "https://w3id.org/catenax/2023/cs/v1", + "https://w3id.org/tractusx-trust/v0.8", "https://identity.foundation/presentation-exchange/submission/v1" ], "@type": "PresentationQueryMessage", @@ -159,7 +159,7 @@ The following are non-normative examples of the JSON body: ```json { "@context": [ - "https://w3id.org/catenax/2023/cs/v1", + "https://w3id.org/tractusx-trust/v0.8", "https://identity.foundation/presentation-exchange/submission/v1" ], "@type": "PresentationQueryMessage",