From 13fd9f353f7c7ea72ab04f47125f8bb356da13f9 Mon Sep 17 00:00:00 2001 From: Rein Krul Date: Wed, 12 Apr 2023 06:50:48 +0200 Subject: [PATCH 01/10] RFC018: Initial version --- SUMMARY.md | 1 + rfc/rfc018-oidc4vci-credential-issuance.md | 69 ++++++++++++++++++++++ 2 files changed, 70 insertions(+) create mode 100644 rfc/rfc018-oidc4vci-credential-issuance.md diff --git a/SUMMARY.md b/SUMMARY.md index f382e52..a1e4a17 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -17,6 +17,7 @@ * [RFC014 Nuts Authorization Credential](rfc/rfc014-authorization-credential.md) * [RFC015 Node identity](rfc/rfc015-node-identity.md) * [RFC017 Distributed Network Protocol (v2) using gRPC](rfc/rfc017-distributed-network-grpc-v2.md) +* [RFC018 Verifiable Credential Issuance using OpenID](rfc/rfc018-oidc4vci-credential-issuance.md) ## templates diff --git a/rfc/rfc018-oidc4vci-credential-issuance.md b/rfc/rfc018-oidc4vci-credential-issuance.md new file mode 100644 index 0000000..ff43543 --- /dev/null +++ b/rfc/rfc018-oidc4vci-credential-issuance.md @@ -0,0 +1,69 @@ +# RFC018 Verifiable Credential Issuance using OpenID + +| | | +|:--------------------------|:----------| +| Nuts foundation | R.G. Krul | +| Request for Comments: 018 | Nedap | + +## Verifiable Credential Issuance using OpenID + +### Abstract + +### Status of document + +This document describes a Nuts standards protocol. + +### Copyright Notice + +![](../.gitbook/assets/license.png) + +This document is released under the [Attribution-ShareAlike 4.0 International \(CC BY-SA 4.0\) license](https://creativecommons.org/licenses/by-sa/4.0/). + +## 1. Introduction + +This specification describes how to apply OpenID for Verifiable Credential Issuance (OIDC4VCI) to issue Verifiable Credentials (VCs) + +## 2. Terminology + +This specification uses the terms "DID", "DID document" and "Service" as defined by the [DID Core Data Model](https://www.w3.org/TR/did-core/), +"Verifiable Credential", "Credential Subject" and "Issuer" as defined by the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/), and +"Wallet", "Client Metadata" and "Credential Offer" as defined by [OpenID 4 Verifiable Credential Issuance](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html). + +## 3. Overview + +While OIDC4VCI is typically designed to be used to issue credentials through a browser or to a mobile wallet app, +this specification describes how to use OIDC4VCI to issue credentials server-to-server, without user interaction from the holder. + +## 3.1 Supported Flows + +Issuers MUST support the pre-authorized code flow to issue credentials. +While OIDC4VCI specifies a PIN to mitigate credential stealing, +implementations MUST NOT require a PIN in server-to-server flows (see Appendix A.1). + +## 4. Client Metadata Discovery using DID documents + +To offer a credential the issuer needs to discover the wallet's credential offer endpoint, which is registered in the client metadata. + +When the wallet is represented by a resolvable DID the client should register a `oidc4vci-wallet-metadata` service on the DID document, +which contains a URL pointing to the client metadata. This indicates the wallet supports receiving credentials according to the OIDC4VCI specification. + +The issuer can resolve this URL and retrieve the client metadata to find the credential offer endpoint. + +## Appendix A: Design decisions + +### A.1 No PIN requirement + +OIDC4VCI specifies a PIN to mitigate credential stealing, +e.g. someone looking over the shoulder of the intended holder standing at a terminal, +quickly scanning the QR code and stealing the resulting credential. +Since this specification describes server-to-server flows, there is no user involved from who the QR code can be stolen +or coerced into giving the QR code. +To prevent eavesdropping, HTTPS MUST be used to protect communication (see Appendix B.1). + +## Appendix B: Security Considerations + +### B.1 Use HTTPS for all exchanges + +To prevent against eavesdropping and man-in-the-middle attacks, all exchanges must be done over HTTPS. +Clients should refuse to connect to plain HTTP endpoints. +Refer to [RFC008 Certificate Structure](rfc008-certificate-structure.md) for requirements regarding these certificates and which Certificate Authorities should be accepted. From e52becdb0dade0215089518e3c738cacfce5b716 Mon Sep 17 00:00:00 2001 From: Rein Krul Date: Wed, 12 Apr 2023 06:52:16 +0200 Subject: [PATCH 02/10] introduction --- rfc/rfc018-oidc4vci-credential-issuance.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rfc/rfc018-oidc4vci-credential-issuance.md b/rfc/rfc018-oidc4vci-credential-issuance.md index ff43543..aed9e0d 100644 --- a/rfc/rfc018-oidc4vci-credential-issuance.md +++ b/rfc/rfc018-oidc4vci-credential-issuance.md @@ -21,7 +21,8 @@ This document is released under the [Attribution-ShareAlike 4.0 International \( ## 1. Introduction -This specification describes how to apply OpenID for Verifiable Credential Issuance (OIDC4VCI) to issue Verifiable Credentials (VCs) +This specification describes how to apply OpenID for Verifiable Credential Issuance (OIDC4VCI) to issue Verifiable Credentials (VCs) +to resolvable DIDs in server-to-server flows, without user (human) interaction from the holder. ## 2. Terminology From 5980e2b5187d860cbb385d8ea12aa0a567b3e4ad Mon Sep 17 00:00:00 2001 From: Rein Krul Date: Wed, 12 Apr 2023 12:29:21 +0200 Subject: [PATCH 03/10] Added credential issuer trust --- rfc/rfc018-oidc4vci-credential-issuance.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/rfc/rfc018-oidc4vci-credential-issuance.md b/rfc/rfc018-oidc4vci-credential-issuance.md index aed9e0d..d17e249 100644 --- a/rfc/rfc018-oidc4vci-credential-issuance.md +++ b/rfc/rfc018-oidc4vci-credential-issuance.md @@ -50,6 +50,12 @@ which contains a URL pointing to the client metadata. This indicates the wallet The issuer can resolve this URL and retrieve the client metadata to find the credential offer endpoint. +## 5. Credential Issuer Trust + +In server-to-server issuance of credentials, there's no user approving the credential offer before requesting it and loading it into the holder's wallet. +Therefore, the holder must make a decision whether to trust credential issuer. +Trust SHOULD be derived from the TLS trust anchors referred to by Appendix B.1. + ## Appendix A: Design decisions ### A.1 No PIN requirement @@ -61,6 +67,14 @@ Since this specification describes server-to-server flows, there is no user invo or coerced into giving the QR code. To prevent eavesdropping, HTTPS MUST be used to protect communication (see Appendix B.1). +### A.2 Trust issuer based on TLS certificates + +Since the TLS trust anchors are curated, trusting credential issuers can be derived from trust TLS server certificates: +Credential issuer identifiers are URLs and thus link to a trusted TLS certificate. + +Future, more involved trust models could involve the issuer presenting a credential from which trust is derived. +For instance, proving that the issuer is a registered legal entity, which can be held accountable. + ## Appendix B: Security Considerations ### B.1 Use HTTPS for all exchanges From 7b55ebc0f5548907b54ea9f94a42792895029d06 Mon Sep 17 00:00:00 2001 From: Rein Krul Date: Tue, 4 Jul 2023 10:36:16 +0200 Subject: [PATCH 04/10] feedback --- SUMMARY.md | 2 +- rfc/rfc018-oidc4vci-credential-issuance.md | 84 ------------- rfc/rfc018-openid-credential-issuance.md | 133 +++++++++++++++++++++ 3 files changed, 134 insertions(+), 85 deletions(-) delete mode 100644 rfc/rfc018-oidc4vci-credential-issuance.md create mode 100644 rfc/rfc018-openid-credential-issuance.md diff --git a/SUMMARY.md b/SUMMARY.md index a1e4a17..c3cddbd 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -17,7 +17,7 @@ * [RFC014 Nuts Authorization Credential](rfc/rfc014-authorization-credential.md) * [RFC015 Node identity](rfc/rfc015-node-identity.md) * [RFC017 Distributed Network Protocol (v2) using gRPC](rfc/rfc017-distributed-network-grpc-v2.md) -* [RFC018 Verifiable Credential Issuance using OpenID](rfc/rfc018-oidc4vci-credential-issuance.md) +* [RFC018 Verifiable Credential Issuance using OpenID](rfc/rfc018-openid-credential-issuance.md) ## templates diff --git a/rfc/rfc018-oidc4vci-credential-issuance.md b/rfc/rfc018-oidc4vci-credential-issuance.md deleted file mode 100644 index d17e249..0000000 --- a/rfc/rfc018-oidc4vci-credential-issuance.md +++ /dev/null @@ -1,84 +0,0 @@ -# RFC018 Verifiable Credential Issuance using OpenID - -| | | -|:--------------------------|:----------| -| Nuts foundation | R.G. Krul | -| Request for Comments: 018 | Nedap | - -## Verifiable Credential Issuance using OpenID - -### Abstract - -### Status of document - -This document describes a Nuts standards protocol. - -### Copyright Notice - -![](../.gitbook/assets/license.png) - -This document is released under the [Attribution-ShareAlike 4.0 International \(CC BY-SA 4.0\) license](https://creativecommons.org/licenses/by-sa/4.0/). - -## 1. Introduction - -This specification describes how to apply OpenID for Verifiable Credential Issuance (OIDC4VCI) to issue Verifiable Credentials (VCs) -to resolvable DIDs in server-to-server flows, without user (human) interaction from the holder. - -## 2. Terminology - -This specification uses the terms "DID", "DID document" and "Service" as defined by the [DID Core Data Model](https://www.w3.org/TR/did-core/), -"Verifiable Credential", "Credential Subject" and "Issuer" as defined by the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/), and -"Wallet", "Client Metadata" and "Credential Offer" as defined by [OpenID 4 Verifiable Credential Issuance](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html). - -## 3. Overview - -While OIDC4VCI is typically designed to be used to issue credentials through a browser or to a mobile wallet app, -this specification describes how to use OIDC4VCI to issue credentials server-to-server, without user interaction from the holder. - -## 3.1 Supported Flows - -Issuers MUST support the pre-authorized code flow to issue credentials. -While OIDC4VCI specifies a PIN to mitigate credential stealing, -implementations MUST NOT require a PIN in server-to-server flows (see Appendix A.1). - -## 4. Client Metadata Discovery using DID documents - -To offer a credential the issuer needs to discover the wallet's credential offer endpoint, which is registered in the client metadata. - -When the wallet is represented by a resolvable DID the client should register a `oidc4vci-wallet-metadata` service on the DID document, -which contains a URL pointing to the client metadata. This indicates the wallet supports receiving credentials according to the OIDC4VCI specification. - -The issuer can resolve this URL and retrieve the client metadata to find the credential offer endpoint. - -## 5. Credential Issuer Trust - -In server-to-server issuance of credentials, there's no user approving the credential offer before requesting it and loading it into the holder's wallet. -Therefore, the holder must make a decision whether to trust credential issuer. -Trust SHOULD be derived from the TLS trust anchors referred to by Appendix B.1. - -## Appendix A: Design decisions - -### A.1 No PIN requirement - -OIDC4VCI specifies a PIN to mitigate credential stealing, -e.g. someone looking over the shoulder of the intended holder standing at a terminal, -quickly scanning the QR code and stealing the resulting credential. -Since this specification describes server-to-server flows, there is no user involved from who the QR code can be stolen -or coerced into giving the QR code. -To prevent eavesdropping, HTTPS MUST be used to protect communication (see Appendix B.1). - -### A.2 Trust issuer based on TLS certificates - -Since the TLS trust anchors are curated, trusting credential issuers can be derived from trust TLS server certificates: -Credential issuer identifiers are URLs and thus link to a trusted TLS certificate. - -Future, more involved trust models could involve the issuer presenting a credential from which trust is derived. -For instance, proving that the issuer is a registered legal entity, which can be held accountable. - -## Appendix B: Security Considerations - -### B.1 Use HTTPS for all exchanges - -To prevent against eavesdropping and man-in-the-middle attacks, all exchanges must be done over HTTPS. -Clients should refuse to connect to plain HTTP endpoints. -Refer to [RFC008 Certificate Structure](rfc008-certificate-structure.md) for requirements regarding these certificates and which Certificate Authorities should be accepted. diff --git a/rfc/rfc018-openid-credential-issuance.md b/rfc/rfc018-openid-credential-issuance.md new file mode 100644 index 0000000..c4bcc48 --- /dev/null +++ b/rfc/rfc018-openid-credential-issuance.md @@ -0,0 +1,133 @@ +# RFC018 Verifiable Credential Issuance using OpenID + +| | | +|:--------------------------|:----------| +| Nuts foundation | R.G. Krul | +| Request for Comments: 018 | Nedap | + +## Verifiable Credential Issuance using OpenID + +### Abstract + +This RFC describes how to use [OpenID4VCI](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) +to issue credentials from a Nuts node, to another Nuts node. It adds security requirements and wallet discovery +to make it applicable to Nuts. + +### Status of document + +This document describes a Nuts standards protocol. + +### Copyright Notice + +![](../.gitbook/assets/license.png) + +This document is released under the [Attribution-ShareAlike 4.0 International \(CC BY-SA 4.0\) license](https://creativecommons.org/licenses/by-sa/4.0/). + +## 1. Introduction + +This specification describes how to apply OpenID Connect for Verifiable Credential Issuance (OpenID4VCI) to issue Verifiable Credentials (VCs) +to resolvable DIDs in server-to-server flows, without user (human) interaction from the holder. + +## 2. Terminology + +This specification uses the terms "DID", "DID document" and "Service" as defined by the [DID Core Data Model](https://www.w3.org/TR/did-core/), +"Verifiable Credential", "Credential Subject", "Holder" and "Issuer" as defined by the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/), and +"Wallet", "Client Metadata" and "Credential Offer" as defined by [OpenID 4 Verifiable Credential Issuance](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html). + +## 3. Overview + +While OpenID4VCI mainly describes issuing credentials through a browser or to a mobile wallet app, +this specification describes how to use OpenID4VCI to issue credentials server-to-server, without user interaction from the holder. + +Nodes MUST support both processes of issuing and receiving credentials over OpenID4VCI. + +## 3.1 Supported Flows + +Issuers MUST support the pre-authorized code flow to issue credentials. +While OpenID4VCI specifies a PIN to mitigate credential stealing, +implementations MUST NOT require a PIN in server-to-server flows (see Appendix A.1). + +## 3.2 Credential Offer Response + +The OpenID4VCI specification does not specify responses for the credential offer. +But since this specification describes server-to-server interaction +a response is useful for the issuer to know whether the credential offer was accepted. + +### 3.2.1 Credential Offer Success Response + +In case the wallet accepted the offer and will try to retrieve the credential, it MUST respond with HTTP status `200 OK`. +If the wallet has retrieved the credential, it can respond with `status` set to `credential_received`. +Below is a non-normative example of such a response: + +```http +HTTP/1.1 200 OK +Content-Type: application/json +Cache-Control: no-store + +{ + "status": "credential_received" +} +``` + +### 3.2.2 Credential Offer Error Response + +This specification extends the specification with the following error responses a wallet MUST support when receiving a credential offer: + +- `invalid_request`: the offer is missing or invalid. +- `invalid_grant`: the offer does not contain a grant the wallet could use to retrieve the credential. + +It MUST respond with HTTP status `400 Bad Request` and a response body containing the error code. + +Below is a non-normative example of such a response: + +```http +HTTP/1.1 400 Bad Request +Content-Type: application/json +Cache-Control: no-store + +{ + "error": "invalid_grant" +} +``` + +## 4. Client Metadata Discovery using DID documents + +To offer a credential the issuer needs to discover the wallet's credential offer endpoint, which is registered in the client metadata. + +To allow a (Nuts) wallet to be discovered, the wallet MUST be represented by a resolvable DID. +The DID document MUST contain a `node-http-services-baseurl` service, which contains the base URL for node-to-node HTTP services. +The issuer appends the following path to it to resolve the client metadata: `/n2n/identity//.well-known/openid-credential-wallet`, +replacing `` with the DID of the wallet holder. + +## 5. Security + +### 5.1 Credential Issuer Trust + +In server-to-server issuance of credentials, there's no user approving the credential offer before requesting it and loading it into the holder's wallet. +Therefore, the holder must make a decision whether to trust the credential issuer. +Trust SHOULD be derived from the TLS trust anchors referred to by section 5.2 (Transport Security). + +### 5.2 Transport Security + +To prevent against eavesdropping and man-in-the-middle attacks, all exchanges MUST be done over HTTPS. +Clients should refuse to connect to plain HTTP endpoints. +Refer to [RFC008 Certificate Structure](rfc008-certificate-structure.md) for requirements regarding these certificates and which Certificate Authorities should be accepted. + +## Appendix A: Design decisions + +### A.1 No PIN requirement + +OpenID4VCI specifies a PIN to mitigate credential stealing, +e.g. someone looking over the shoulder of the intended holder standing at a terminal, +quickly scanning the QR code and stealing the resulting credential. +Since this specification describes server-to-server flows, there is no user involved from who the QR code can be stolen +or coerced into giving the QR code. +To prevent eavesdropping, HTTPS MUST be used to protect communication (see Appendix B.1). + +### A.2 Trust issuer based on TLS certificates + +Since the TLS trust anchors are curated, trusting credential issuers can be derived from trust TLS server certificates: +Credential issuer identifiers are URLs and thus link to a trusted TLS certificate. + +Future, more involved trust models could involve the issuer presenting a credential from which trust is derived. +For instance, proving that the issuer is a registered legal entity, which can be held accountable. From bea08003a482481531a346823631561c349d5464 Mon Sep 17 00:00:00 2001 From: Rein Krul Date: Tue, 4 Jul 2023 10:36:55 +0200 Subject: [PATCH 05/10] abstract --- rfc/rfc018-openid-credential-issuance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfc/rfc018-openid-credential-issuance.md b/rfc/rfc018-openid-credential-issuance.md index c4bcc48..478c9b4 100644 --- a/rfc/rfc018-openid-credential-issuance.md +++ b/rfc/rfc018-openid-credential-issuance.md @@ -10,8 +10,8 @@ ### Abstract This RFC describes how to use [OpenID4VCI](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) -to issue credentials from a Nuts node, to another Nuts node. It adds security requirements and wallet discovery -to make it applicable to Nuts. +to issue credentials from a Nuts node, to another Nuts node. It adds security requirements, wallet discovery and +server-to-server responses to make it applicable to Nuts. ### Status of document From 963f8a86c0cf2fe857a53dc410ae075462c19723 Mon Sep 17 00:00:00 2001 From: Rein Krul Date: Tue, 4 Jul 2023 11:53:44 +0200 Subject: [PATCH 06/10] added list of things that don't need to be supported --- rfc/rfc018-openid-credential-issuance.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/rfc/rfc018-openid-credential-issuance.md b/rfc/rfc018-openid-credential-issuance.md index 478c9b4..ae249f6 100644 --- a/rfc/rfc018-openid-credential-issuance.md +++ b/rfc/rfc018-openid-credential-issuance.md @@ -47,6 +47,17 @@ Issuers MUST support the pre-authorized code flow to issue credentials. While OpenID4VCI specifies a PIN to mitigate credential stealing, implementations MUST NOT require a PIN in server-to-server flows (see Appendix A.1). +The following from the OpenID4VCI specification does not need to be supported: + +- Authorization code flow +- Credential offers: + - with `string` values, referring to a credential's `id` in `credentials_supported` + - specified as `credential_offer_uri` parameter +- Batching +- Deferred credential requests +- Credential types other than JSON-LD +- Requesting an updated credential + ## 3.2 Credential Offer Response The OpenID4VCI specification does not specify responses for the credential offer. From 44e9cb63bdfbc78161cb14ea5cd990546c25b0e8 Mon Sep 17 00:00:00 2001 From: Rein Krul Date: Tue, 11 Jul 2023 14:27:25 +0200 Subject: [PATCH 07/10] feedback --- rfc/rfc018-openid-credential-issuance.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/rfc/rfc018-openid-credential-issuance.md b/rfc/rfc018-openid-credential-issuance.md index ae249f6..6004d37 100644 --- a/rfc/rfc018-openid-credential-issuance.md +++ b/rfc/rfc018-openid-credential-issuance.md @@ -66,8 +66,10 @@ a response is useful for the issuer to know whether the credential offer was acc ### 3.2.1 Credential Offer Success Response -In case the wallet accepted the offer and will try to retrieve the credential, it MUST respond with HTTP status `200 OK`. -If the wallet has retrieved the credential, it can respond with `status` set to `credential_received`. +In case the wallet considers the offer valid, it MUST respond with HTTP status `200 OK`. +This is regardless of whether the wallet will actually revrieve the wallet. + +If the wallet decides to retrieve the credential synchronously, it SHOULD respond with `status` set to `credential_received`. Below is a non-normative example of such a response: ```http From a6d0f3103f20684e43d409b65c76b949ed4b469a Mon Sep 17 00:00:00 2001 From: Rein Krul Date: Wed, 12 Jul 2023 13:47:42 +0200 Subject: [PATCH 08/10] feedback --- rfc/rfc018-openid-credential-issuance.md | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/rfc/rfc018-openid-credential-issuance.md b/rfc/rfc018-openid-credential-issuance.md index 6004d37..61aa89f 100644 --- a/rfc/rfc018-openid-credential-issuance.md +++ b/rfc/rfc018-openid-credential-issuance.md @@ -41,22 +41,16 @@ this specification describes how to use OpenID4VCI to issue credentials server-t Nodes MUST support both processes of issuing and receiving credentials over OpenID4VCI. -## 3.1 Supported Flows +## 3.1 Supported Flows and Features -Issuers MUST support the pre-authorized code flow to issue credentials. -While OpenID4VCI specifies a PIN to mitigate credential stealing, -implementations MUST NOT require a PIN in server-to-server flows (see Appendix A.1). +Conforming implementations MUST support the following features: -The following from the OpenID4VCI specification does not need to be supported: - -- Authorization code flow -- Credential offers: +- Pre-authorized code flow +- Credential offer: + - with `credential_offer` parameter - with `string` values, referring to a credential's `id` in `credentials_supported` - - specified as `credential_offer_uri` parameter -- Batching -- Deferred credential requests -- Credential types other than JSON-LD -- Requesting an updated credential +- Credentials in JSON-LD format +- Issuer- and wallet metadata ## 3.2 Credential Offer Response From ad829ce53490efdd1797f5d5d5287c310b25e4f6 Mon Sep 17 00:00:00 2001 From: Rein Krul Date: Fri, 28 Jul 2023 06:57:59 +0200 Subject: [PATCH 09/10] feedback --- rfc/rfc018-openid-credential-issuance.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/rfc/rfc018-openid-credential-issuance.md b/rfc/rfc018-openid-credential-issuance.md index 61aa89f..d50add2 100644 --- a/rfc/rfc018-openid-credential-issuance.md +++ b/rfc/rfc018-openid-credential-issuance.md @@ -49,7 +49,7 @@ Conforming implementations MUST support the following features: - Credential offer: - with `credential_offer` parameter - with `string` values, referring to a credential's `id` in `credentials_supported` -- Credentials in JSON-LD format +- Credentials in JSON-LD (`ldp_vc`) format - Issuer- and wallet metadata ## 3.2 Credential Offer Response @@ -61,9 +61,9 @@ a response is useful for the issuer to know whether the credential offer was acc ### 3.2.1 Credential Offer Success Response In case the wallet considers the offer valid, it MUST respond with HTTP status `200 OK`. -This is regardless of whether the wallet will actually revrieve the wallet. +This is regardless of whether the wallet will actually retrieve the wallet. -If the wallet decides to retrieve the credential synchronously, it SHOULD respond with `status` set to `credential_received`. +If the wallet immediately retrieved the credential, it SHOULD respond with `status` set to `credential_received`. Below is a non-normative example of such a response: ```http @@ -137,4 +137,4 @@ Since the TLS trust anchors are curated, trusting credential issuers can be deri Credential issuer identifiers are URLs and thus link to a trusted TLS certificate. Future, more involved trust models could involve the issuer presenting a credential from which trust is derived. -For instance, proving that the issuer is a registered legal entity, which can be held accountable. +For instance, proving that the issuer is a registered legal entity. From 92a321e27316b6d0c04c5287a11a34297d383384 Mon Sep 17 00:00:00 2001 From: Rein Krul Date: Fri, 28 Jul 2023 06:58:36 +0200 Subject: [PATCH 10/10] conflicts --- SUMMARY.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/SUMMARY.md b/SUMMARY.md index c3cddbd..781e2eb 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -18,6 +18,8 @@ * [RFC015 Node identity](rfc/rfc015-node-identity.md) * [RFC017 Distributed Network Protocol (v2) using gRPC](rfc/rfc017-distributed-network-grpc-v2.md) * [RFC018 Verifiable Credential Issuance using OpenID](rfc/rfc018-openid-credential-issuance.md) +* [RFC019 Employee Identity Authentication Means](rfc/rfc019-employee-identity-means.md) +* [RFC020 Authorization credential extension](rfc/rfc020-authorization-credential-extension.md) ## templates