Prepare for release (#49)

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`.
+

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)

specifications/M1/credential.issuance.protocol.md → 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
 

specifications/M1/identity.protocol.base.md → 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
 

specifications/M1/verifiable.presentation.protocol.md → 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",