Add authentication

input/images-source/gfi-001.plantuml

@@ -0,0 +1,16 @@
+@startuml GFI-001
+
+skinparam roundcorner 20
+skinparam defaultFontName Arial 
+hide footbox
+activate issuer
+
+!pragma teoz true
+
+participant  verifier as "Verifier"
+participant  issuer as "Issuer/Holder"
+
+verifier -> issuer: Resolve DID Document Request [GFI-001]
+issuer --> verifier: DID Document Response [GFI-001]
+
+@enduml

input/images-source/gfi-003.plantuml

@@ -0,0 +1,16 @@
+@startuml GFI-003
+
+skinparam roundcorner 20
+skinparam defaultFontName Arial 
+hide footbox
+activate issuer
+
+!pragma teoz true
+
+participant  verifier as "Verifier"
+participant  issuer as "Issuer"
+
+verifier -> issuer: Revocation Status Information Request [GFI-003]
+issuer --> verifier: Revocation Status Information Response [GFI-003]
+
+@enduml

input/images-source/gfi-004.plantuml

@@ -0,0 +1,19 @@
+@startuml GFI-004
+
+skinparam roundcorner 20
+skinparam defaultFontName Arial 
+hide footbox
+autoactivate on
+
+!pragma teoz true
+
+participant  holder as "Holder"
+participant  verifier as "Verifier"
+
+holder -> verifier: Nonce Request
+verifier --> holder: Nonce Response
+
+holder -> verifier: Access Token Request
+verifier --> holder: Access Token Response
+
+@enduml

input/images-source/gfi-005.plantuml

@@ -0,0 +1,18 @@
+@startuml GFI-005
+
+skinparam roundcorner 20
+skinparam defaultFontName Arial 
+hide footbox
+
+!pragma teoz true
+
+participant  client as "Client"
+participant  RS as "Resource Server"
+
+client -> client: Create DPoP Proof
+client -> RS: Authenticated API Request
+activate RS
+RS --> client: Authenticated API Response
+deactivate RS
+
+@enduml

input/images-source/gfi-006.plantuml

@@ -0,0 +1,16 @@
+@startuml GFI-006
+
+skinparam roundcorner 20
+skinparam defaultFontName Arial 
+hide footbox
+autoactivate on
+
+!pragma teoz true
+
+participant RS as "Resource Server"
+participant AS as "Verifier"
+
+RS -> AS: Introspect Access Token Request
+AS --> RS: Introspect Access Token Response
+
+@enduml

input/pagecontent/GFI-001.md

@@ -0,0 +1,97 @@
+### Scope
+
+The Request key material transaction returns a document containing the public key material for a given entity.
+
+### Actor Roles
+
+| Actor         | Role                                                                               |
+| ------------- | ---------------------------------------------------------------------------------- |
+| Verifier      | Requests key material for a given entity based on a Decentralized Identifier (DID) |
+| Issuer/Holder | Responds to the request with the public key material associated with the DID       |
+
+### Referenced standards
+
+- [DID Core](https://www.w3.org/TR/did-core/)
+- [DID Resolution](https://www.w3.org/TR/did-resolution/)
+- [DID Web Method](https://w3c-ccg.github.io/did-method-web/)
+
+### Messages
+
+1. Resolve DID Document Request
+2. DID Document Response
+
+<div>
+{% include GFI-001.svg %}
+</div>
+
+#### Resolve DID Document Request
+
+##### Trigger events
+
+A verifier needs to verify the authenticity of a signature on a verifiable credential or presentation.
+
+##### Message semantics
+
+A verifier initiates a resolve DID document request using a HTTP GET request to the DID web url. No further parameters are required.
+The DID web url is constructed following the rules as defined in the [DID Web Method](https://w3c-ccg.github.io/did-method-web/).
+
+##### Example
+
+Example did:web
+
+```
+did:web:example.com:user:alice
+```
+
+Which resolves to the DID document at:
+
+```
+GET https://example.com/user/alice/did.json
+```
+
+#### DID Document Response
+
+##### Trigger events
+
+The requested party responds to the resolve DID document request.
+
+##### Message semantics
+
+The requested party responds with a HTTP 200 OK response containing the DID document in the body of the response. The DID document is a JSON-LD document conforming to the [DID Core](https://www.w3.org/TR/did-core/) specification.
+
+##### Example
+
+```json
+{
+  "@context": "https://www.w3.org/ns/did/v1",
+  "id": "did:web:example.com:user:alice",
+  "verificationMethod": [
+    {
+      "id": "did:web:example.com:user:alice#key-1",
+      "type": "JsonWebKey2020",
+      "controller": "did:web:example.com:user:alice",
+      "publicKeyJwk": {
+        "kty": "EC",
+        "crv": "P-256",
+        "x": "...",
+        "y": "..."
+      }
+    }
+  ],
+  "authentication": ["did:web:example.com:user:alice#key-1"]
+}
+```
+
+##### Expected actions
+
+**Case 1**: The DID document is found on the server.
+
+`HTTP 200` (OK) is returned as the HTTP status code.
+
+A DID document is returned in the body of the response.
+
+**Case 2**: The DID document is not found on the server.
+
+`HTTP 404` (Not Found) is returned as the HTTP status code.
+
+No body is returned in the response.

input/pagecontent/GFI-002.md

@@ -0,0 +1,26 @@
+### Scope
+
+The Issue Claims transaction describes the process of issuing verifiable claims from an authoritative issuer to a holder. The claims are typically encapsulated within a verifiable credential, which the holder can later present to verifiers as proof of certain attributes or qualifications.
+The Issue Claims transaction can be initiated by the holder or the issuer, depending on the use case and the relationship between the parties involved.
+
+#### Optionality
+
+This transaction is optional and provides a standardized way requesting and transferring verifiable claims between an issuer and a holder. It is possible to request, issue and transfer these claims using other protocols such as email or other messaging systems.
+
+### Actor Roles
+
+| Actor  | Role                                                                        |
+| ------ | --------------------------------------------------------------------------- |
+| Issuer | Issues verifiable claims to a holder in the form of a verifiable credential |
+| Holder | Receives verifiable claims from the issuer and stores them securely         |
+
+### Referenced standards
+
+- [Verifiable Credentials Data Model 1.0](https://www.w3.org/TR/vc-data-model/)
+- [OpenID4VCI](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html)
+
+### Messages
+
+1. Credential Offer
+2. Credential Request
+3. Credential Response

input/pagecontent/GFI-003.md

@@ -0,0 +1,129 @@
+### Scope
+
+The transaction Request Revocation Status is used by a verifier to determine the revocation status of a verifiable credential presented by a holder. The verifier sends a request to the revocation registry or authority specified in the credential to determine if the credential is still valid or has been revoked.
+
+### Actor Roles
+
+| Actor    | Role                                                                                   |
+| -------- | -------------------------------------------------------------------------------------- |
+| Verifier | Requests the revocation information of a verifiable credential                         |
+| Issuer   | Provides the revocation information which the verifier can use to determine the status |
+
+### Referenced standards
+
+- [Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model/)
+- [Bitstring Status List v1.0](https://www.w3.org/TR/vc-bitstring-status-list/)
+
+### Messages
+
+1. Revocation Status Information Request
+1. Revocation Status Information Response
+
+<div>
+{% include GFI-003.svg %}
+</div>
+
+#### Revocation Status Information Request
+
+##### Trigger events
+
+- A Holder presents a verifiable credential to a verifier and the verifier needs to check the revocation status of the credential.
+- A timer based event to refresh the revocation status information based on the `ValidUntil` field in the status list credential.
+
+##### Message semantics
+
+The verifier initiates a revocation status information request using a HTTP GET request to the revocation URL specified in the verifiable credential under the `credentialStatus` property. Such as specified in the [Bitstring Status List v1.0](https://www.w3.org/TR/vc-bitstring-status-list/) specification.
+
+##### Example
+
+Note: these examples are non normative, for implementation the actual specifications should be followed.
+
+Example of a revocable Verifiable Credential:
+
+```json
+{
+  "@context": [
+    "https://www.w3.org/2018/credentials/v1",
+    "https://www.w3.org/2018/credentials/examples/v1",
+    "https://w3id.org/vc/status-list/2021/v1"
+  ],
+  "id": "http://example.edu/credentials/3732",
+  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
+  "issuer": "https://example.edu/issuers/14",
+  "issuanceDate": "2020-03-10T04:24:12.164Z",
+  "credentialSubject": {
+    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "degree": {
+      "type": "BachelorDegree",
+      "name": "Bachelor of Science and Arts"
+    }
+  },
+  "credentialStatus": {
+    "id": "https://example.edu/status/24#94567",
+    "type": "BitstringStatusListEntry",
+    "statusPurpose": "revocation",
+    "statusListIndex": "94567",
+    "statusListCredential": "https://example.edu/status/24"
+  },
+  "proof": {
+    "type": "RsaSignature2018",
+    "created": "2020-03-10T04:24:12Z",
+    "proofPurpose": "assertionMethod",
+    "verificationMethod": "https://example.edu/issuers/keys/1",
+    "jws": "..."
+  }
+}
+```
+
+This results in the following request:
+
+```
+GET https://example.edu/status/24
+```
+
+#### Revocation Status Information Response
+
+##### Trigger events
+
+The requested party responds to the revocation status information request.
+
+##### Message semantics
+
+The Issuer should respond with the latest version of the status list credential, signed with the Issuer's proofing method.
+
+##### Example
+
+Note: these examples are non normative, for implementation the actual specifications should be followed.
+
+Example of a Status List Credential response:
+
+```json
+{
+  "@context": [
+    "https://www.w3.org/2018/credentials/v1",
+    "https://w3id.org/vc/status-list/2021/v1"
+  ],
+  "id": "https://example.edu/status/24",
+  "type": ["VerifiableCredential", "StatusList2021Credential"],
+  "issuer": "https://example.edu/issuers/14",
+  "validFrom": "2025-03-10T04:24:12Z",
+  "ValidUntil": "2025-03-10T08:24:12Z",
+  "credentialSubject": {
+    "id": "https://example.edu/status/24#list",
+    "type": "BitstringStatusList",
+    "statusPurpose": "revocation",
+    "encodedList": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAPgG6AAB"
+  },
+  "proof": {
+    "type": "RsaSignature2018",
+    "created": "2020-03-10T04:24:12Z",
+    "proofPurpose": "assertionMethod",
+    "verificationMethod": "https://example.edu/issuers/keys/1",
+    "jws": "..."
+  }
+}
+```
+
+##### Expected actions
+
+The verifier processes the status list credential as specified by the [Validate Algorithm section of the specification](https://www.w3.org/TR/vc-bitstring-status-list/#validate-algorithm) to determine the revocation status of the verifiable credential presented by the holder. The verifier decodes the `encodedList` field to obtain the bitstring representing the revocation status of credentials. The verifier checks the bit at the index specified in the `statusListIndex` field of the verifiable credential's `credentialStatus` property. If the bit is set to `1`, the credential is revoked; if it is set to `0`, the credential is valid.