diff --git a/examples/credential_request_iso_mdl.json b/examples/credential_request_iso_mdl.json new file mode 100644 index 00000000..ed43bcc7 --- /dev/null +++ b/examples/credential_request_iso_mdl.json @@ -0,0 +1,8 @@ +{ + "format": "mso_mdoc", + "doctype": "org.iso.18013.5.1.mDL", + "proof": { + "proof_type": "jwt", + "jwt": "eyJraWQiOiJkaWQ6ZXhhbXBsZ...KPxgihac0aW9EkL1nOzM" + } +} \ No newline at end of file diff --git a/examples/credential_response_jwt_vc_json.txt b/examples/credential_response_jwt_vc_json.txt index 2c55576f..33831260 100644 --- a/examples/credential_response_jwt_vc_json.txt +++ b/examples/credential_response_jwt_vc_json.txt @@ -4,21 +4,42 @@ Content-Type: application/json Cache-Control: no-store { - "credential": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI - 6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3Ln - czLm9yZy8yMDE4L2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cDovL2V4YW1wb - GUuZWR1L2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwi - VW5pdmVyc2l0eURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9leGFtcGxlLmV - kdS9pc3N1ZXJzLzU2NTA0OSIsImlzc3VhbmNlRGF0ZSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIi - wiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxY - zI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IkJh - Y2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMifX19LCJpc3MiOiJodHRwczovL2V4YW1wbGUuZWR - 1L2lzc3VlcnMvNTY1MDQ5IiwibmJmIjoxMjYyMzA0MDAwLCJqdGkiOiJodHRwOi8vZXhhbXBsZS - 5lZHUvY3JlZGVudGlhbHMvMzczMiIsInN1YiI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2Z - jFjMjc2ZTEyZWMyMSJ9.z5vgMTK1nfizNCg5N-niCOL3WUIAL7nXy-nGhDZYO_-PNGeE-0djCpW - AMH8fD8eWSID5PfkPBYkx_dfLJnQ7NA", + "credentials": [ + { + "credential": "eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6I + nVybjppZXRmOnBhcmFtczpvYXV0aDpqd2stdGh1bWJwcmludDpzaGEtMjU2O + m1sVXBvZzd2RWV3RkJlbTZVbDA5YzJkdFR3YzhkRnpWcElEWDNzcUdXVzAif + Q.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC + 9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZW + RlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoiaHR0cHM6Ly9jcmVkZW50aW + FsLWlzc3Vlci5leGFtcGxlLmNvbS9jcmVkZW50aWFscy8zNzMyIiwidHlwZS + I6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCIsIlVuaXZlcnNpdHlEZWdyZWVDcm + VkZW50aWFsIl0sImlzc3VlciI6Imh0dHBzOi8vY3JlZGVudGlhbC1pc3N1ZX + IuZXhhbXBsZS5jb20iLCJpc3N1YW5jZURhdGUiOiIyMDI1LTAxLTAxVDAwOj + AwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmp3azpleU + pyYVdRaU9pSjFjbTQ2YVdWMFpqcHdZWEpoYlhNNmIyRjFkR2c2YW5kckxYUm + 9kVzFpY0hKcGJuUTZjMmhoTFRJMU5qcFdZa3BQVTNacWVGVTJURGhETjBkVl + R6UmtjMmhKV1ZZemVtSjJSbmRyV1VJME0xbEtOVXQwZERoRklpd2lhM1I1SW + pvaVJVTWlMQ0pqY25ZaU9pSlFMVEkxTmlJc0ltRnNaeUk2SWtWVE1qVTJJaX + dpZUNJNklrMWtReTFQUzNFMFFWRktabFpEV0RWNmNGRnZURGhxTkZaRlpuWl + FXRGs0ZEZVNWFIaGpUbGhIY204aUxDSjVJam9pYm5OWGJtWmlOazVYYzBzek + 9VSklMV2hCWVZOclExTmxORUo1YldWT2MyTktSVjl6WVVRelJETmlUU0o5Ii + wiZGVncmVlIjp7InR5cGUiOiJCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYW + NoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fSwiaXNzIjoiaHR0cHM6Ly + 9jcmVkZW50aWFsLWlzc3Vlci5leGFtcGxlLmNvbSIsIm5iZiI6MTczNTY4OT + YwMCwianRpIjoiaHR0cHM6Ly9jcmVkZW50aWFsLWlzc3Vlci5leGFtcGxlLm + NvbS9jcmVkZW50aWFscy8zNzMyIiwic3ViIjoiZGlkOmp3azpleUpyYVdRaU + 9pSjFjbTQ2YVdWMFpqcHdZWEpoYlhNNmIyRjFkR2c2YW5kckxYUm9kVzFpY0 + hKcGJuUTZjMmhoTFRJMU5qcFdZa3BQVTNacWVGVTJURGhETjBkVlR6UmtjMm + hKV1ZZemVtSjJSbmRyV1VJME0xbEtOVXQwZERoRklpd2lhM1I1SWpvaVJVTW + lMQ0pqY25ZaU9pSlFMVEkxTmlJc0ltRnNaeUk2SWtWVE1qVTJJaXdpZUNJNk + lrMWtReTFQUzNFMFFWRktabFpEV0RWNmNGRnZURGhxTkZaRlpuWlFXRGs0ZE + ZVNWFIaGpUbGhIY204aUxDSjVJam9pYm5OWGJtWmlOazVYYzBzek9VSklMV2 + hCWVZOclExTmxORUo1YldWT2MyTktSVjl6WVVRelJETmlUU0o5In0.k13xQC + nQIKAIuwQIbg37dwlNr8D6_2YUQtDTVQCq-ZsjcXxHagGC_VIZtd7RpR8OvB + zTBHVwrBRD-_RzoV2Ofg" + } + ], "c_nonce": "fGFF7UkhLa", "c_nonce_expires_in": 86400 - } - - +} diff --git a/examples/credential_response_ldp_vc.txt b/examples/credential_response_ldp_vc.txt index 4c44f6d8..3bb5a763 100644 --- a/examples/credential_response_ldp_vc.txt +++ b/examples/credential_response_ldp_vc.txt @@ -3,34 +3,38 @@ Content-Type: application/json Cache-Control: no-store { - "credential": { - "@context": [ - "https://www.w3.org/2018/credentials/v1", - "https://www.w3.org/2018/credentials/examples/v1" - ], - "id": "http://example.edu/credentials/3732", - "type": [ - "VerifiableCredential", - "UniversityDegreeCredential" - ], - "issuer": "https://example.edu/issuers/565049", - "issuanceDate": "2010-01-01T00:00:00Z", - "credentialSubject": { - "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", - "degree": { - "type": "BachelorDegree", - "name": "Bachelor of Science and Arts" + "credentials": [ + { + "credential": { + "@context": [ + "https://www.w3.org/2018/credentials/v1", + "https://www.w3.org/2018/credentials/examples/v1" + ], + "id": "http://example.edu/credentials/3732", + "type": [ + "VerifiableCredential", + "UniversityDegreeCredential" + ], + "issuer": "https://example.edu/issuers/565049", + "issuanceDate": "2010-01-01T00:00:00Z", + "credentialSubject": { + "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", + "degree": { + "type": "BachelorDegree", + "name": "Bachelor of Science and Arts" + } + }, + "proof": { + "type": "Ed25519Signature2020", + "created": "2022-02-25T14:58:43Z", + "verificationMethod": "https://example.edu/issuers/565049#key-1", + "proofPurpose": "assertionMethod", + "proofValue": "zeEdUoM7m9cY8ZyTpey83yBKeBcmcvbyrEQzJ19rD2UXArU2U1 + jPGoEtrRvGYppdiK37GU4NBeoPakxpWhAvsVSt" + } } - }, - "proof": { - "type": "Ed25519Signature2020", - "created": "2022-02-25T14:58:43Z", - "verificationMethod": "https://example.edu/issuers/565049#key-1", - "proofPurpose": "assertionMethod", - "proofValue": "zeEdUoM7m9cY8ZyTpey83yBKeBcmcvbyrEQzJ19rD2UXArU2U1jPGoEt - rRvGYppdiK37GU4NBeoPakxpWhAvsVSt" } - }, + ], "c_nonce": "fGFF7UkhLa", "c_nonce_expires_in": 86400 } \ No newline at end of file diff --git a/examples/credential_response_mso_mdoc.txt b/examples/credential_response_mso_mdoc.txt index 1b22ada0..8198b8d4 100644 --- a/examples/credential_response_mso_mdoc.txt +++ b/examples/credential_response_mso_mdoc.txt @@ -3,5 +3,9 @@ Content-Type: application/json Cache-Control: no-store { - "credential": "omppc3N1ZXJBdXRohEOhASahG...ArQwggKwMIICVqADAgEC" + "credentials": [ + { + "credential": "omppc3N1ZXJBdXRohEOhASahG...ArQwggKwMIICVqADAgEC" + } + ] } \ No newline at end of file diff --git a/examples/credential_response_sd_jwt_vc.txt b/examples/credential_response_sd_jwt_vc.txt index 52b815a0..3862a5db 100644 --- a/examples/credential_response_sd_jwt_vc.txt +++ b/examples/credential_response_sd_jwt_vc.txt @@ -3,34 +3,40 @@ Content-Type: application/json Cache-Control: no-store { - "credential": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogInZjK3NkLWp3dCIsI - CJraWQiOiAiZG9jLXNpZ25lci0wNS0yNS0yMDIyIn0.eyJfc2QiOiBbIjA5dktyS - k1PbHlUV00wc2pwdV9wZE9CVkJRMk0xeTNLaHBINTE1blhrcFkiLCAiMnJzakdiY - UMwa3k4bVQwcEpyUGlvV1RxMF9kYXcxc1g3NnBvVWxnQ3diSSIsICJFa084ZGhXM - GRIRUpidlVIbEVfVkNldUM5dVJFTE9pZUxaaGg3WGJVVHRBIiwgIklsRHpJS2VpW - mREd3BxcEs2WmZieXBoRnZ6NUZnbldhLXNONndxUVhDaXciLCAiSnpZakg0c3Zsa - UgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBLdVZ1N - nh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1S - lFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiamRyVEU4WWNiWTRFa - WZ1Z2loaUFlX0JQZWt4SlFaSUNlaVVRd1k5UXF4SSIsICJqc3U5eVZ1bHdRUWxoR - mxNXzNKbHpNYVNGemdsaFFHMERwZmF5UXdMVUs0Il0sICJpc3MiOiAiaHR0cHM6L - y9leGFtcGxlLmNvbS9pc3N1ZXIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6I - DE4ODMwMDAwMDAsICJ2Y3QiOiAiaHR0cHM6Ly9jcmVkZW50aWFscy5leGFtcGxlL - mNvbS9pZGVudGl0eV9jcmVkZW50aWFsIiwgIl9zZF9hbGciOiAic2hhLTI1NiIsI - CJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydiI6ICJQLTI1NiIsICJ4I - jogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTGlsRGxzN3ZDZUdlbWMiL - CAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVmZ1ZWNDRTZ0NGpUOUYyS - FpRIn19fQ.oiDeF5QD8nCi8NHpKCVBsyitThK1xdRPtMePDdEIqJFY1BKtd5PhYj - XLUVg3VuQZqyuOUev0OQAgu1KuMY0DNA~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl - 3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV - 9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtd - lZBIiwgImVtYWlsIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW - 5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMD - EiXQ~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7InN0cmV - ldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24 - iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJBSng - tMDk1VlBycFR0TjRRTU9xUk9BIiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0 - ~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImlzX292ZXJfMTgiLCB0cnVlXQ~ - WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImlzX292ZXJfMjEiLCB0cnVlXQ~W - yJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImlzX292ZXJfNjUiLCB0cnVlXQ~" + "credentials": [ + { + "credential": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogInZjK3NkLWp3d + CIsICJraWQiOiAiZG9jLXNpZ25lci0wNS0yNS0yMDIyIn0.eyJfc2QiOiBbI + jA5dktySk1PbHlUV00wc2pwdV9wZE9CVkJRMk0xeTNLaHBINTE1blhrcFkiL + CAiMnJzakdiYUMwa3k4bVQwcEpyUGlvV1RxMF9kYXcxc1g3NnBvVWxnQ3diS + SIsICJFa084ZGhXMGRIRUpidlVIbEVfVkNldUM5dVJFTE9pZUxaaGg3WGJVV + HRBIiwgIklsRHpJS2VpWmREd3BxcEs2WmZieXBoRnZ6NUZnbldhLXNONndxU + VhDaXciLCAiSnpZakg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN + 0VQWWxTRSIsICJQb3JGYnBLdVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQ + TJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1SlFhSHlLVlFaVTlVZEdFMHc1cnREc + 3JaemZVYW9tTG8iLCAiamRyVEU4WWNiWTRFaWZ1Z2loaUFlX0JQZWt4SlFaS + UNlaVVRd1k5UXF4SSIsICJqc3U5eVZ1bHdRUWxoRmxNXzNKbHpNYVNGemdsa + FFHMERwZmF5UXdMVUs0Il0sICJpc3MiOiAiaHR0cHM6Ly9leGFtcGxlLmNvb + S9pc3N1ZXIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6IDE4ODMwMDAwM + DAsICJ2Y3QiOiAiaHR0cHM6Ly9jcmVkZW50aWFscy5leGFtcGxlLmNvbS9pZ + GVudGl0eV9jcmVkZW50aWFsIiwgIl9zZF9hbGciOiAic2hhLTI1NiIsICJjb + mYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydiI6ICJQLTI1NiIsICJ4I + jogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTGlsRGxzN3ZDZUdlb + WMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVmZ1ZWNDRTZ0N + GpUOUYySFpRIn19fQ.oiDeF5QD8nCi8NHpKCVBsyitThK1xdRPtMePDdEIqJ + FY1BKtd5PhYjXLUVg3VuQZqyuOUev0OQAgu1KuMY0DNA~WyIyR0xDNDJzS1F + 2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU + 9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJd~WyI2S + Wo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VAZXhhb + XBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX2 + 51bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ~WyJRZ19PNjR6cUF4ZTQxMmE + xMDhpcm9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyB + NYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkF + ueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJBSngtMDk1VlBycFR0TjR + RTU9xUk9BIiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0~WyJQYzMzSk0 + yTGNoY1VfbEhnZ3ZfdWZRIiwgImlzX292ZXJfMTgiLCB0cnVlXQ~WyJHMDJO + U3JRZmpGWFE3SW8wOXN5YWpBIiwgImlzX292ZXJfMjEiLCB0cnVlXQ~WyJsa + 2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImlzX292ZXJfNjUiLCB0cnVlXQ~" + } + ] } \ No newline at end of file diff --git a/examples/issuer_jwks.json b/examples/issuer_jwks.json new file mode 100644 index 00000000..b3541d34 --- /dev/null +++ b/examples/issuer_jwks.json @@ -0,0 +1,12 @@ +{ + "jwks": [ + { + "kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:mlUpog7vEewFBem6Ul09c2dtTwc8dFzVpIDX3sqGWW0", + "kty": "EC", + "crv": "P-256", + "alg": "ES256", + "x": "_LC1FTUl0MltKAOQzXNsofVMpWFV2obLGrNCat_CQ-g", + "y": "kBjoyjNuMVAOq--qVUgylDoLKuMdk4imS-Kk5ahuYIU" + } + ] +} \ No newline at end of file diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index daf022e5..c1cbcbd2 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -7,7 +7,7 @@ keyword = ["security", "openid", "ssi"] [seriesInfo] name = "Internet-Draft" -value = "openid-4-verifiable-credential-issuance-1_0-14" +value = "openid-4-verifiable-credential-issuance-1_0-15" status = "standard" [[author]] @@ -56,7 +56,9 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S # Terminology -This specification uses the terms "Access Token", "Authorization Endpoint", "Authorization Request", "Authorization Response", "Authorization Code Grant", "Authorization Server", "Client", "Client Authentication", "Client Identifier", "Grant Type", "Refresh Token", "Token Endpoint", "Token Request" and "Token Response" defined by OAuth 2.0 [@!RFC6749], the terms "End-User", "Entity", and "Request Object" as defined by OpenID Connect Core [@!OpenID.Core], the term "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [@!RFC7519], the term "JOSE Header" and "Base64url Encoding" defined by JSON Web Signature (JWS) [@!RFC7515]. +This specification uses the terms "Access Token", "Authorization Endpoint", "Authorization Request", "Authorization Response", "Authorization Code Grant", "Authorization Server", "Client", "Client Authentication", "Client Identifier", "Grant Type", "Refresh Token", "Token Endpoint", "Token Request" and "Token Response" defined by OAuth 2.0 [@!RFC6749], the terms "End-User", "Entity", and "Request Object" as defined by OpenID Connect Core [@!OpenID.Core], the term "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [@!RFC7519], the term "JOSE Header" defined by JSON Web Signature (JWS) [@!RFC7515]. + +Base64url-encoded denotes the URL-safe base64 encoding without padding defined in Section 2 of [@!RFC7515]. This specification also defines the following terms. In the case where a term has a definition that differs, the definition below is authoritative for this specification. @@ -118,6 +120,7 @@ Deferred Credential Issuance: This specification defines an API for Credential issuance provided by a Credential Issuer. The API is comprised of the following endpoints: * A mandatory Credential Endpoint from which Credentials can be issued (see (#credential-endpoint)). From this endpoint, one Credential, or multiple Credentials with the same Credential Dataset can be issued in one request. +* An optional Nonce Endpoint from which a fresh `c_nonce` value can be obtained to be used in proof of possession of key material in a subsequent request to the Credential Endpoint (see (#nonce-endpoint)). * An optional Deferred Credential Endpoint to allow for the deferred delivery of Credentials (see (#deferred-credential-issuance)). * An optional mechanism for the Credential Issuer to make a Credential Offer to the Wallet to encourage the Wallet to start the issuance flow (see (#credential-offer-endpoint)). * An optional mechanism for the Credential Issuer to receive from the Wallet notification(s) of the status of the Credential(s) that have been issued. @@ -137,7 +140,6 @@ Existing OAuth 2.0 mechanisms are extended as following: * A new authorization details [@!RFC9396] type `openid_credential` is defined to convey the details about the Credentials (including Credential Dataset, Credential Formats, and Credential types) the Wallet wants to obtain (see (#authorization-details)). * Client metadata is used to convey the Wallet's metadata. The new Client metadata parameter `credential_offer_endpoint` is added to allow a Wallet (acting as OAuth 2.0 client) to publish its Credential Offer Endpoint (see (#client-metadata)). * Authorization Endpoint: The additional parameter `issuer_state` is added to convey state in the context of processing an issuer-initiated Credential Offer (see (#credential-authz-request)). Additional parameters `wallet_issuer` and `user_hint` are added to enable the Credential Issuer to request Verifiable Presentations from the calling Wallet during Authorization Request processing. -* Token Endpoint: Optional response parameters `c_nonce` and `c_nonce_expires_in` are added to the Token Endpoint, and Credential Endpoint to provide the Client with a nonce to be used for proof of possession of key material in a subsequent request to the Credential Endpoint (see (#token-response)). ## Core Concepts @@ -333,7 +335,9 @@ This endpoint is used by a Credential Issuer that is already interacting with an ## Credential Offer {#credential-offer} -The Credential Issuer sends Credential Offer using an HTTP GET request or an HTTP redirect to the Wallet's Credential Offer Endpoint defined in (#client-metadata). +The Credential Issuer makes a Credential Offer by allowing the End-User to invoke the Wallet using the Wallet's Credential Offer Endpoint defined in (#client-metadata). For example, by clicking a link and/or rendering a QR code containing the Credential Offer that the End-User can scan in a wallet or an arbitrary camera application. + +Credential Issuers MAY also communicate Credential Offers directly to a Wallet's backend but any mechanism for doing so is currently outside the scope of this specification. The Credential Offer object, which is a JSON-encoded object with the Credential Offer parameters, can be sent by value or by reference. @@ -342,8 +346,6 @@ The Credential Offer contains a single URI query parameter, either `credential_o * `credential_offer`: Object with the Credential Offer parameters. This MUST NOT be present when the `credential_offer_uri` parameter is present. * `credential_offer_uri`: String that is a URL using the `https` scheme referencing a resource containing a JSON object with the Credential Offer parameters. This MUST NOT be present when the `credential_offer` parameter is present. -The Credential Issuer MAY render a QR code containing the Credential Offer that can be scanned by the End-User using a Wallet, or a link that the End-User can click. - For security considerations, see (#credential-offer-security). ### Credential Offer Parameters {#credential-offer-parameters} @@ -354,6 +356,9 @@ This specification defines the following parameters for the JSON-encoded Credent * `credential_configuration_ids`: REQUIRED. Array of unique strings that each identify one of the keys in the name/value pairs stored in the `credential_configurations_supported` Credential Issuer metadata. The Wallet uses these string values to obtain the respective object that contains information about the Credential being offered as defined in (#credential-issuer-parameters). For example, these string values can be used to obtain `scope` values to be used in the Authorization Request. * `grants`: OPTIONAL. Object indicating to the Wallet the Grant Types the Credential Issuer's Authorization Server is prepared to process for this Credential Offer. Every grant is represented by a name/value pair. The name is the Grant Type identifier; the value is an object that contains parameters either determining the way the Wallet MUST use the particular grant and/or parameters the Wallet MUST send with the respective request(s). If `grants` is not present or is empty, the Wallet MUST determine the Grant Types the Credential Issuer's Authorization Server supports using the respective metadata. When multiple grants are present, it is at the Wallet's discretion which one to use. +Additional Credential Offer parameters MAY be defined and used. +The Wallet MUST ignore any unrecognized parameters. + The following values are defined by this specification: * Grant Type `authorization_code`: @@ -446,6 +451,10 @@ The request parameter `authorization_details` defined in Section 2 of [@!RFC9396 * `credential_configuration_id`: REQUIRED when `format` parameter is not present. String specifying a unique identifier of the Credential being described in the `credential_configurations_supported` map in the Credential Issuer Metadata as defined in (#credential-issuer-parameters). The referenced object in the `credential_configurations_supported` map conveys the details, such as the format, for issuance of the requested Credential. This specification defines Credential Format specific Issuer Metadata in (#format-profiles). It MUST NOT be present if `format` parameter is present. * `format`: REQUIRED when `credential_configuration_id` parameter is not present. String identifying the format of the Credential the Wallet needs. This Credential Format Identifier determines further claims in the authorization details object needed to identify the Credential type in the requested format. This specification defines Credential Format Profiles in (#format-profiles). It MUST NOT be present if `credential_configuration_id` parameter is present. +Additional `authorization_details` data fields MAY be defined and used +when the `type` value is `openid_credential`. +Note that this effectively defines an authorization details type that is never considered invalid due to unknown fields. + The following is a non-normative example of an `authorization_details` object with a `credential_configuration_id`: <{{examples/authorization_details.json}} @@ -526,6 +535,10 @@ This specification defines the following request parameters that can be supplied Note: When processing the Authorization Request, the Credential Issuer MUST take into account that the `issuer_state` is not guaranteed to originate from this Credential Issuer in all circumstances. It could have been injected by an attacker. +Additional Authorization Request parameters MAY be defined and used, +as described in [@!RFC6749]. +The Authorization Server MUST ignore any unrecognized parameters. + ### Pushed Authorization Request Use of Pushed Authorization Requests is RECOMMENDED to ensure confidentiality, integrity, and authenticity of the request data and to avoid issues caused by large requests sizes. @@ -605,6 +618,10 @@ If the Token Request contains a scope value related to Credential issuance and t When the Pre-Authorized Grant Type is used, it is RECOMMENDED that the Credential Issuer issues an Access Token valid only for the Credentials indicated in the Credential Offer (see (#credential-offer)). The Wallet SHOULD obtain a separate Access Token if it wants to request issuance of any Credentials that were not included in the Credential Offer, but were discoverable from the Credential Issuer's `credential_configurations_supported` metadata parameter. +Additional Token Request parameters MAY be defined and used, +as described in [@!RFC6749]. +The Authorization Server MUST ignore any unrecognized parameters. + Below is a non-normative example of a Token Request in an Authorization Code Flow: ``` @@ -648,12 +665,15 @@ The Authorization Server might decide to authorize issuance of multiple instance In addition to the response parameters defined in [@!RFC6749], the Authorization Server MAY return the following parameters: -* `c_nonce`: OPTIONAL. String containing a nonce to be used when creating a proof of possession of the key proof (see (#credential-request)). When received, the Wallet MUST use this nonce value for its subsequent requests until the Credential Issuer provides a fresh nonce. -* `c_nonce_expires_in`: OPTIONAL. Number denoting the lifetime in seconds of the `c_nonce`. * `authorization_details`: REQUIRED when the `authorization_details` parameter is used to request issuance of a certain Credential Configuration as defined in (#authorization-details). It MUST NOT be used otherwise. It is an array of objects, as defined in Section 7 of [@!RFC9396]. In addition to the parameters defined in (#authorization-details), this specification defines the following parameter to be used with the authorization details type `openid_credential` in the Token Response: * `credential_identifiers`: REQUIRED. Array of strings, each uniquely identifying a Credential Dataset that can be issued using the Access Token returned in this response. Each of these Credential Datasets corresponds to the same Credential Configuration in the `credential_configurations_supported` parameter of the Credential Issuer metadata. The Wallet MUST use these identifiers together with an Access Token in subsequent Credential Requests. - -Note: The `credential_identifiers` parameter cannot be used when the `scope` parameter is used in the Authorization Request to request issuance of a Credential. + +Additional Token Response parameters MAY be defined and used, +as described in [@!RFC6749]. +The Wallet MUST ignore any unrecognized parameters in the Token Response. +An included `authorization_details` parameter MAY also have additional data fields defined and used +when the `type` value is `openid_credential`. +The Wallet MUST ignore any unrecognized data fields in the `authorization_details` present in the Token Response. Below is a non-normative example of a Token Response when the `authorization_details` parameter was used to request issuance of a certain Credential type: @@ -664,10 +684,8 @@ Cache-Control: no-store { "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp..sHQ", - "token_type": "bearer", + "token_type": "Bearer", "expires_in": 86400, - "c_nonce": "tZignsnFbp", - "c_nonce_expires_in": 86400, "authorization_details": [ { "type": "openid_credential", @@ -710,6 +728,48 @@ Cache-Control: no-store } ``` +# Nonce Endpoint {#nonce-endpoint} + +This endpoint allows a Client to acquire a fresh `c_nonce` value without the overhead of a full Credential Request. A Credential Issuer that requires `c_nonce` values to be incorporated into proofs in the Credential Request (see (#credential-request)) MUST offer a Nonce Endpoint. + +The `nonce_endpoint` Credential Issuer Metadata parameter, as defined in (#credential-issuer-parameters), contains the URL of the Credential Issuer's Nonce Endpoint. + + +## Nonce Request {#nonce-request} + +A request for a nonce is made by sending an HTTP POST request to the URL provided in the `nonce_endpoint` Credential Issuer Metadata parameter. + +Below is a non-normative example of a Nonce Request: + +``` +POST /nonce HTTP/1.1 +Host: credential-issuer.example.com +Content-Length: 0 +``` + +## Nonce Response {#nonce-response} + +The Credential Issuer provides a nonce value in the HTTP response with a 2xx status code and the following parameters included as top-level members in the message body of the HTTP response using the application/json media type: + +* `c_nonce`: REQUIRED. String containing a nonce to be used when creating a proof of possession of the key proof (see (#credential-request)). +* `c_nonce_expires_in`: OPTIONAL. Number denoting the lifetime in seconds of the `c_nonce`. This value serves only as a hint to the Client, indicating how long the Credential Issuer is likely to accept the `c_nonce` as valid. + +Due to the temporal and contextually sensitive nature of the `c_nonce` value, the Credential Issuer MUST make the response uncacheable by adding a `Cache-Control` header field including the value `no-store`. + +Below is a non-normative example of a Nonce Response: + +``` +HTTP/1.1 200 OK +Content-Type: application/json +Cache-Control: no-store + +{ + "c_nonce": "wKI4LT17ac15ES9bw8ac4", + "c_nonce_expires_in": 120 +} +``` + + # Credential Endpoint {#credential-endpoint} The Credential Endpoint issues one or more Credentials of the same Credential Configuration and Credential Dataset (as approved by the End-User) upon presentation of a valid Access Token representing this approval. Support for this endpoint is REQUIRED. @@ -750,17 +810,22 @@ A Client makes a Credential Request to the Credential Endpoint by sending the fo The `proof_type` parameter is an extension point that enables the use of different types of proofs for different cryptographic schemes. -The proof(s) in the `proof` or `proofs` parameter MUST incorporate the Credential Issuer Identifier (audience), and optionally a `c_nonce` value generated by the Authorization Server or the Credential Issuer to allow the Credential Issuer to detect replay. The way that data is incorporated depends on the key proof type. In a JWT, for example, the `c_nonce` value is conveyed in the `nonce` claim, whereas the audience is conveyed in the `aud` claim. In a Linked Data proof, for example, the `c_nonce` is included as the `challenge` element in the key proof object and the Credential Issuer (the intended audience) is included as the `domain` element. +The proof(s) in the `proof` or `proofs` parameter MUST incorporate the Credential Issuer Identifier (audience), and optionally a `c_nonce` value generated by the Credential Issuer to allow the Credential Issuer to detect replay. The way that data is incorporated depends on the key proof type. In a JWT, for example, the `c_nonce` value is conveyed in the `nonce` claim, whereas the audience is conveyed in the `aud` claim. In a Linked Data proof, for example, the `c_nonce` is included as the `challenge` element in the key proof object and the Credential Issuer (the intended audience) is included as the `domain` element. Either the `proof` or `proofs` parameter MUST be present if the `proof_types_supported` parameter is present in the `credential_configurations_supported` parameter of the Issuer metadata for the requested Credential. +The initial `c_nonce` value can be returned in a Nonce Response as defined in (#nonce-response), or in a Credential Error Response as defined in (#issuer-provided-nonce). + +Additional Credential Request parameters MAY be defined and used. +The Credential Issuer MUST ignore any unrecognized parameters. + Below is a non-normative example of a Credential Request for a Credential in [@ISO.18013-5] format using the Credential configuration identifier and a key proof type `jwt`: ``` POST /credential HTTP/1.1 Host: server.example.com Content-Type: application/json -Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW +Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW { "credential_configuration_id": "org.iso.18013.5.1.mDL", @@ -777,7 +842,7 @@ Below is a non-normative example of a Credential Request for two Credential inst POST /credential HTTP/1.1 Host: server.example.com Content-Type: application/json -Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW +Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW { "credential_identifier": "CivilEngineeringDegree-2023", @@ -839,12 +904,14 @@ This specification defines the following proof types: * `jwt`: A JWT [@!RFC7519] is used for proof of possession. When a `proof_type` parameter in a `proof` object is set to `jwt`, it MUST also contain a `jwt` parameter that includes a JWT as defined in (#jwt-proof-type). When a `proofs` object is using a `jwt` proof type, it MUST include a `jwt` parameter with its value being an array of JWTs, where each JWT is formed as defined in (#jwt-proof-type). * `ldp_vp`: A W3C Verifiable Presentation object signed using the Data Integrity Proof [@VC_Data_Integrity] as defined in [@VC_DATA_2.0] or [@VC_DATA] is used for proof of possession. When a `proof_type` parameter in a `proof` object is set to `ldp_vp`, it MUST also contain an `ldp_vp` parameter that includes a [W3C Verifiable Presentation](https://www.w3.org/TR/vc-data-model-2.0/#presentations-0) defined in (#ldp-vp-proof-type). When a `proofs` object is using a `ldp_vp` proof type, it MUST include an `ldp_vp` parameter with its value being an array of [W3C Verifiable Presentations](https://www.w3.org/TR/vc-data-model-2.0/#presentations-0), where each of these W3C Verifiable Presentation is formed as defined in (#ldp-vp-proof-type). +Additional proof types MAY be defined and used. + #### `jwt` Proof Type {#jwt-proof-type} The JWT MUST contain the following elements: * in the JOSE header, - * `alg`: REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry [@IANA.JOSE.ALGS]. It MUST NOT be `none` or an identifier for a symmetric algorithm (MAC). + * `alg`: REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry [@IANA.JOSE]. It MUST NOT be `none` or an identifier for a symmetric algorithm (MAC). * `typ`: REQUIRED. MUST be `openid4vci-proof+jwt`, which explicitly types the key proof JWT as recommended in Section 3.11 of [@!RFC8725]. * `kid`: OPTIONAL. JOSE Header containing the key ID. If the Credential shall be bound to a DID, the `kid` refers to a DID URL which identifies a particular key in the DID Document that the Credential shall be bound to. It MUST NOT be present if `jwk` is present. * `jwk`: OPTIONAL. JOSE Header containing the key material the new Credential shall be bound to. It MUST NOT be present if `kid` is present. @@ -859,7 +926,7 @@ The JWT MUST contain the following elements: The Credential Issuer MUST validate that the JWT used as a proof is actually signed by a key identified in the JOSE Header. -Cryptographic algorithm names used in the `proof_signing_alg_values_supported` Credential Issuer metadata parameter for this proof type SHOULD be one of those defined in [@IANA.JOSE.ALGS]. +Cryptographic algorithm names used in the `proof_signing_alg_values_supported` Credential Issuer metadata parameter for this proof type SHOULD be one of those defined in [@IANA.JOSE]. Below is a non-normative example of a `proof` parameter (with line breaks within values for display purposes only): @@ -971,9 +1038,11 @@ These checks may be performed in any order. ## Credential Response {#credential-response} -Credential Response can be immediate or deferred. The Credential Issuer MAY be able to immediately issue a requested Credential and send it to the Client. +Credential Response can contain one or more Credentials depending on the Credential Request. + +Credential Response can be immediate or deferred and can contain one or more Credentials with the same Credential Configuration and Credential Dataset depending on the Credential Request. The Credential Issuer MAY be able to immediately issue requested Credentials and send them to the Client. In other cases, the Credential Issuer MAY NOT be able to immediately issue a requested Credential and would send a `transaction_id` parameter to the Client to be used later to receive a Credential when it is ready. -In other cases, the Credential Issuer MAY NOT be able to immediately issue a requested Credential and would want to send a `transaction_id` parameter to the Client to be used later to receive a Credential when it is ready. The HTTP status code MUST be 202 (see Section 15.3.3 of [@!RFC9110]). +The HTTP status code MUST be 202 (see Section 15.3.3 of [@!RFC9110]). If the Client requested an encrypted response by including the `credential_response_encryption` object in the request, the Credential Issuer MUST encode the information in the Credential Response as a JWT using the parameters from the `credential_response_encryption` object. If the Credential Response is encrypted, the media type of the response MUST be set to `application/jwt`. If encryption was requested in the Credential Request and the Credential Response is not encrypted, the Client SHOULD reject the Credential Response. @@ -981,17 +1050,20 @@ If the Credential Response is not encrypted, the media type of the response MUST The following parameters are used in the JSON-encoded Credential Response body: -* `credential`: OPTIONAL. Contains issued Credential. It MUST NOT be used if `credentials` or `transaction_id` parameter is present. It MAY be a string or an object, depending on the Credential Format. See (#format-profiles) for the Credential Format-specific encoding requirements. -* `credentials`: OPTIONAL. Contains an array of issued Credentials. It MUST NOT be used if `credential` or `transaction_id` parameter is present. The values in the array MAY be a string or an object, depending on the Credential Format. See (#format-profiles) for the Credential Format-specific encoding requirements. -* `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This claim is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if `credential` or `credentials` is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet. +* `credentials`: OPTIONAL. Contains an array of one or more issued Credentials. It MUST NOT be used if the `transaction_id` parameter is present. The elements of the array MUST be objects. This specification defines the following parameters to be used inside this object: + * `credential`: REQUIRED. Contains one issued Credential. It MAY be a string or an object, depending on the Credential Format. See Appendix A for the Credential Format-specific encoding requirements. +* `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This parameter is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if the `credentials` parameter is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet. * `c_nonce`: OPTIONAL. String containing a nonce to be used to create a proof of possession of key material when requesting a Credential (see (#credential-request)). When received, the Wallet MUST use this nonce value for its subsequent Credential Requests until the Credential Issuer provides a fresh nonce. * `c_nonce_expires_in`: OPTIONAL. Number denoting the lifetime in seconds of the `c_nonce`. -* `notification_id`: OPTIONAL. String identifying an issued Credential that the Wallet includes in the Notification Request as defined in (#notification). This parameter MUST NOT be present if `credential` parameter is not present. +* `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present. The encoding of the Credential returned in the `credential` parameter depends on the Credential Format. Credential Formats expressed as binary data MUST be base64url-encoded and returned as a string. More details such as Credential Format Identifiers are defined in the Credential Format Profiles in (#format-profiles). +Additional Credential Response parameters MAY be defined and used. +The Wallet MUST ignore any unrecognized parameters. + Below is a non-normative example of a Credential Response in an immediate issuance flow for a Credential in JWT VC format (JSON encoded): ``` @@ -1000,13 +1072,17 @@ Content-Type: application/json Cache-Control: no-store { - "credential": "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L", + "credentials": [ + { + "credential": "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L" + } + ], "c_nonce": "fGFF7UkhLa", - "c_nonce_expires_in": 86400 + "c_nonce_expires_in": 86400 } ``` -Below is a non-normative example of a Credential Response in an immediate issuance flow for multiple Credential instances in JWT VC format (JSON encoded): +Below is a non-normative example of a Credential Response in an immediate issuance flow for multiple Credential instances in JWT VC format (JSON encoded) with an additional `notification_id` parameter: ``` HTTP/1.1 200 OK @@ -1014,11 +1090,16 @@ Content-Type: application/json { "credentials": [ - "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L", - "YXNkZnNhZGZkamZqZGFza23....29tZTIzMjMyMzIzMjMy" + { + "credential": "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L" + }, + { + "credential": "YXNkZnNhZGZkamZqZGFza23....29tZTIzMjMyMzIzMjMy" + } ], "c_nonce": "fGFF7UkhLa", - "c_nonce_expires_in": 86400 + "c_nonce_expires_in": 86400, + "notification_id": "3fwe98js" } ``` @@ -1077,7 +1158,7 @@ Cache-Control: no-store The Credential Issuer MAY provide the Client with a `c_nonce` as defined in (#credential-response) in a Credential Error Response using `invalid_proof` error code defined in (#credential-error-response) if the Credential Issuer Metadata contains `proof_types_supported` indicating a key proof is required for the requested Credential. Depending on the Credential Issuer policy, this occurs if they receive a Credential Request without a `c_nonce` or with an invalid `c_nonce` value included in the proof(s) in the `proof` or `proofs` parameter. -If the Client has not received a `c_nonce` and the Credential Issuer Metadata contains `proof_types_supported` indicating a key proof is required for the requested Credential, the Client MUST send a Credential Request that contains a `proof` or `proofs` parameter that is fully valid but does not include a `c_nonce` value. It is the Credential Issuer policy whether or not a `c_nonce` value is required in the key proofs. +If the Credential Issuer Metadata contains a `nonce_endpoint` and a `proof_types_supported` indicating a key proof is required for the requested Credential and the Client does not have a valid `c_nonce`, the Client MUST obtain a `c_nonce` value from the `nonce_endpoint` and send a Credential Request that contains a `proof` or `proofs` parameter that includes a `c_nonce` value. It is the Credential Issuer policy whether or not a `c_nonce` value is required in the key proofs. If the Client received a `c_nonce`, the `c_nonce` value MUST be incorporated in the respective parameter in the `proof` or `proofs` object. @@ -1099,9 +1180,9 @@ Cache-Control: no-store # Deferred Credential Endpoint {#deferred-credential-issuance} -This endpoint is used to issue a Credential previously requested at the Credential Endpoint in cases where the Credential Issuer was not able to immediately issue this Credential. Support for this endpoint is OPTIONAL. +This endpoint is used to issue one or more Credentials previously requested at the Credential Endpoint in cases where the Credential Issuer was not able to immediately issue this Credential. Support for this endpoint is OPTIONAL. -The Wallet MUST present to the Deferred Endpoint an Access Token that is valid for the issuance of the Credential previously requested at the Credential Endpoint. +The Wallet MUST present to the Deferred Endpoint an Access Token that is valid for the issuance of the Credential(s) previously requested at the Credential Endpoint. Communication with the Deferred Credential Endpoint MUST utilize TLS. @@ -1115,13 +1196,16 @@ The following parameter is used in the Deferred Credential Request: The Credential Issuer MUST invalidate the `transaction_id` after the Credential for which it was meant has been obtained by the Wallet. +Additional Deferred Credential Request parameters MAY be defined and used. +The Credential Issuer MUST ignore any unrecognized parameters. + The following is a non-normative example of a Deferred Credential Request: ``` POST /deferred_credential HTTP/1.1 Host: server.example.com Content-Type: application/json -Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW +Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW { "transaction_id": "8xLOxBtZp8" @@ -1130,10 +1214,32 @@ Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW ## Deferred Credential Response {#deferred-credential-response} -The Deferred Credential Response uses the `credential` parameter as defined in (#credential-response). +The Deferred Credential Response uses the `credentials` and `notification_id` parameters as defined in (#credential-response). + +Additional Deferred Credential Response parameters MAY be defined and used. +The Wallet MUST ignore any unrecognized parameters. The Deferred Credential Response MUST be sent using the `application/json` media type. +The following is a non-normative example of a Deferred Credential Response: + +``` +HTTP/1.1 200 OK +Content-Type: application/json + +{ + "credentials": [ + { + "credential": "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L" + }, + { + "credential": "YXNkZnNhZGZkamZqZGFza23....29tZTIzMjMyMzIzMjMy" + } + ], + "notification_id": "3fwe98js" +} +``` + ## Deferred Credential Error Response {#deferred-credential-error-response} When the Deferred Credential Request is invalid or the Credential is not available yet, the Credential Issuer constructs the error response as defined in (#credential-error-response). @@ -1157,7 +1263,7 @@ Cache-Control: no-store # Notification Endpoint {#notification-endpoint} -This endpoint is used by the Wallet to notify the Credential Issuer of certain events for issued Credentials. These events enable the Credential Issuer to take subsequent actions after issuance. The Credential Issuer needs to return one or more `notification_id` parameters in the Credential Response for the Wallet to be able to use this endpoint. Support for this endpoint is OPTIONAL. The Issuer cannot assume that a notification will be sent for every issued Credential since the use of this Endpoint is not mandatory for the Wallet. +This endpoint is used by the Wallet to notify the Credential Issuer of certain events for issued Credentials. These events enable the Credential Issuer to take subsequent actions after issuance. The Credential Issuer needs to return one `notification_id` parameter per Credential Response or Deferred Credential Response for the Wallet to be able to use this endpoint. Support for this endpoint is OPTIONAL. The Issuer cannot assume that a notification will be sent for every issued Credential since the use of this Endpoint is not mandatory for the Wallet. The Wallet MUST present to the Notification Endpoint a valid Access Token issued at the Token Endpoint as defined in (#token-endpoint). @@ -1169,12 +1275,15 @@ Communication with the Notification Endpoint MUST utilize TLS. ## Notification Request {#notification} -The Wallet sends an HTTP POST request to the Notification Endpoint with the following parameters in the entity-body and using the `application/json` media type. If the Wallet supports the Notification Endpoint, the Wallet MAY send one or more Notification Requests per Credential issued. +The Wallet sends an HTTP POST request to the Notification Endpoint with the following parameters in the entity-body and using the `application/json` media type. If the Wallet supports the Notification Endpoint, the Wallet MAY send one or more Notification Requests per `notification_id` value received. +* `notification_id`: REQUIRED. String received in the Credential Response or Deferred Credential Response identifying an issuance flow that contained one or more Credentials with the same Credential Configuration and Credential Dataset. +* `event`: REQUIRED. Type of the notification event. It MUST be a case sensitive string whose value is either `credential_accepted`, `credential_failure`, or `credential_deleted`. `credential_accepted` is to be used when the Credentials were successfully stored in the Wallet, with or without user action. `credential_deleted` is to be used when the unsuccessful Credential issuance was caused by a user action. In all other unsuccessful cases, `credential_failure` is to be used. Partial errors during batch credential issuance (e.g., one of the Credentials in the batch could not be stored) MUST be treated as the overall issuance flow failing. -* `notification_id`: REQUIRED. String received in the Credential Response. -* `event`: REQUIRED. Type of the notification event. It MUST be a case sensitive string whose value is either `credential_accepted`, `credential_failure`, or `credential_deleted`. `credential_accepted` is to be used when the Credential was successfully stored in the Wallet, with or without user action. `credential_deleted` is to be used when the unsuccessful Credential issuance was caused by a user action. In all other unsuccessful cases, `credential_failure` is to be used. * `event_description`: OPTIONAL. Human-readable ASCII [@!USASCII] text providing additional information, used to assist the Credential Issuer developer in understanding the event that occurred. Values for the `event_description` parameter MUST NOT include characters outside the set `%x20-21 / %x23-5B / %x5D-7E`. +Additional Notification Request parameters MAY be defined and used. +The Credential Issuer MUST ignore any unrecognized parameters. + Below is a non-normative example of a Notification Request when a credential was successfully accepted by the End-User: ``` @@ -1245,6 +1354,10 @@ This specification defines the following new Client Metadata parameter in additi * `credential_offer_endpoint`: OPTIONAL. Credential Offer Endpoint of a Wallet. +Additional Client metadata parameters MAY be defined and used, +as described in [@!RFC7591]. +The Wallet MUST ignore any unrecognized parameters. + ### Client Metadata Retrieval {#client-metadata-retrieval} How to obtain Client Metadata is out of scope of this specification. Profiles of this specification MAY also define static sets of Client Metadata values to be used. @@ -1291,6 +1404,7 @@ This specification defines the following Credential Issuer Metadata parameters: * `credential_issuer`: REQUIRED. The Credential Issuer's identifier, as defined in (#credential-issuer-identifier). * `authorization_servers`: OPTIONAL. Array of strings, where each string is an identifier of the OAuth 2.0 Authorization Server (as defined in [@!RFC8414]) the Credential Issuer relies on for authorization. If this parameter is omitted, the entity providing the Credential Issuer is also acting as the Authorization Server, i.e., the Credential Issuer's identifier is used to obtain the Authorization Server metadata. The actual OAuth 2.0 Authorization Server metadata is obtained from the `oauth-authorization-server` well-known location as defined in Section 3 of [@!RFC8414]. When there are multiple entries in the array, the Wallet may be able to determine which Authorization Server to use by querying the metadata; for example, by examining the `grant_types_supported` values, the Wallet can filter the server to use based on the grant type it plans to use. When the Wallet is using `authorization_server` parameter in the Credential Offer as a hint to determine which Authorization Server to use out of multiple, the Wallet MUST NOT proceed with the flow if the `authorization_server` Credential Offer parameter value does not match any of the entries in the `authorization_servers` array. * `credential_endpoint`: REQUIRED. URL of the Credential Issuer's Credential Endpoint, as defined in (#credential-request). This URL MUST use the `https` scheme and MAY contain port, path, and query parameter components. +* `nonce_endpoint`: OPTIONAL. URL of the Credential Issuer's Nonce Endpoint, as defined in (#nonce-endpoint). This URL MUST use the `https` scheme and MAY contain port, path, and query parameter components. If omitted, the Credential Issuer does not support the Nonce Endpoint. * `deferred_credential_endpoint`: OPTIONAL. URL of the Credential Issuer's Deferred Credential Endpoint, as defined in (#deferred-credential-issuance). This URL MUST use the `https` scheme and MAY contain port, path, and query parameter components. If omitted, the Credential Issuer does not support the Deferred Credential Endpoint. * `notification_endpoint`: OPTIONAL. URL of the Credential Issuer's Notification Endpoint, as defined in (#notification-endpoint). This URL MUST use the `https` scheme and MAY contain port, path, and query parameter components. If omitted, the Credential Issuer does not support the Notification Endpoint. * `credential_response_encryption`: OPTIONAL. Object containing information about whether the Credential Issuer supports encryption of the Credential Credential Response on top of TLS. @@ -1333,18 +1447,25 @@ Depending on the Credential Format, additional parameters might be present in th The Authorization Server MUST be able to determine from the Issuer metadata what claims are disclosed by the requested Credentials to be able to render meaningful End-User consent. +Additional Credential Issuer metadata parameters MAY be defined and used. +The Wallet MUST ignore any unrecognized parameters. + The following is a non-normative example of Credential Issuer metadata of a Credential in the IETF SD-JWT VC [@!I-D.ietf-oauth-sd-jwt-vc] format: <{{examples/credential_metadata_sd_jwt_vc.json}} Note: The Client MAY use other mechanisms to obtain information about the Verifiable Credentials that a Credential Issuer can issue. -## OAuth 2.0 Authorization Server Metadata +## OAuth 2.0 Authorization Server Metadata {#as-metadata} This specification also defines a new OAuth 2.0 Authorization Server metadata [@!RFC8414] parameter to publish whether the Authorization Server that the Credential Issuer relies on for authorization supports anonymous Token Requests with the Pre-Authorized Grant Type. It is defined as follows: * `pre-authorized_grant_anonymous_access_supported`: OPTIONAL. A boolean indicating whether the Credential Issuer accepts a Token Request with a Pre-Authorized Code but without a `client_id`. The default is `false`. +Additional Authorization Server metadata parameters MAY be defined and used, +as described in [@!RFC8414]. +The Wallet MUST ignore any unrecognized parameters. + # Security Considerations {#security-considerations} ## Trust between Wallet and Issuer @@ -1694,25 +1815,25 @@ regulation), the Credential Issuer should properly authenticate the Wallet and e - + OpenID Connect Core 1.0 incorporating errata set 2 - - NRI + + NAT.Consulting - - Ping Identity + + Yubico - - Microsoft + + Self-Issued Consulting - - Google + + Google - - Salesforce + + Disney - + @@ -1776,18 +1897,9 @@ regulation), the Credential Issuer should properly authenticate the Wallet and e - + - JSON Web Signature and Encryption Algorithms - - IANA - - - - - - - COSE Algorithms + JSON Object Signing and Encryption (JOSE) IANA @@ -1863,7 +1975,7 @@ regulation), the Credential Issuer should properly authenticate the Wallet and e Connect2id - + @@ -1887,6 +1999,16 @@ regulation), the Credential Issuer should properly authenticate the Wallet and e + + + Uniform Resource Identifier (URI) Schemes + + IANA + + + + + REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC @@ -1936,7 +2058,7 @@ When the `format` value is `jwt_vc_json`, the entire Credential Offer, Authoriza #### Credential Issuer Metadata {#server-metadata-jwt-vc-json} -Cryptographic algorithm names used in the `credential_signing_alg_values_supported` parameter SHOULD be one of those defined in [@IANA.JOSE.ALGS]. +Cryptographic algorithm names used in the `credential_signing_alg_values_supported` parameter SHOULD be one of those defined in [@IANA.JOSE]. The following additional Credential Issuer metadata parameters are defined for this Credential Format for use in the `credential_configurations_supported` parameter, in addition to those defined in (#credential-issuer-parameters). @@ -1974,6 +2096,10 @@ The following is a non-normative example of a Credential Response with Credentia <{{examples/credential_response_jwt_vc_json.txt}} +The following is the dereferenced document for the Issuer HTTP URL identifier that matches the Credential in the above example: + +<{{examples/issuer_jwks.json}} + ### VC Secured using Data Integrity, using JSON-LD, with a Proof Suite Requiring Linked Data Canonicalization #### Format Identifier @@ -2107,7 +2233,7 @@ The Credential Format Identifier is `vc+sd-jwt`. ### Credential Issuer Metadata {#server-metadata-sd-jwt-vc} -Cryptographic algorithm names used in the `credential_signing_alg_values_supported` parameter SHOULD be one of those defined in [@IANA.JOSE.ALGS]. +Cryptographic algorithm names used in the `credential_signing_alg_values_supported` parameter SHOULD be one of those defined in [@IANA.JOSE]. The following additional Credential Issuer metadata parameters are defined for this Credential Format for use in the `credential_configurations_supported` parameter, in addition to those defined in (#credential-issuer-parameters). @@ -2146,76 +2272,113 @@ The following is a non-normative example of a Credential Response containing a C # IANA Considerations -## Sub-Namespace Registration +## OAuth URI Registry -This specification registers the following URN in the IANA "OAuth URI" registry [@!IANA.OAuth.Parameters] established by [@!RFC6755]. +This specification registers the following URN +in the IANA "OAuth URI" registry [@IANA.OAuth.Parameters] +established by [@!RFC6755]. -* URN: urn:ietf:params:oauth:grant-type:pre-authorized_code +### urn:ietf:params:oauth:grant-type:pre-authorized_code + +* URN: `urn:ietf:params:oauth:grant-type:pre-authorized_code` * Common Name: Pre-Authorized Code * Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Reference: (#token-request) of this specification +* Reference: (#credential-offer-parameters) of this specification ## OAuth Parameters Registry -This specification registers the following parameter names in the IANA "OAuth Parameters" registry [@!IANA.OAuth.Parameters] established by [@!RFC6749]. +This specification registers the following OAuth parameters +in the IANA "OAuth Parameters" registry [@IANA.OAuth.Parameters] +established by [@!RFC6749]. -* Parameter Name: wallet_issuer +### wallet_issuer + +* Name: `wallet_issuer` * Parameter Usage Location: authorization request * Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net * Reference: (#credential-authz-request) of this specification -* Parameter Name: user_hint +### user_hint + +* Name: `user_hint` * Parameter Usage Location: authorization request * Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net * Reference: (#credential-authz-request) of this specification -* Parameter Name: issuer_state +### issuer_state + +* Name: `issuer_state` * Parameter Usage Location: authorization request * Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net * Reference: (#credential-authz-request) of this specification -* Parameter Name: pre-authorized_code +### pre-authorized_code + +* Name: `pre-authorized_code` * Parameter Usage Location: token request * Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net * Reference: (#token-request) of this specification -* Parameter Name: tx_code +### tx_code + +* Name: `tx_code` * Parameter Usage Location: token request * Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net * Reference: (#token-request) of this specification -* Parameter Name: c_nonce -* Parameter Usage Location: token response -* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Reference: (#token-response) of this specification +### credential_identifiers -* Parameter Name: c_nonce_expires_in +* Name: `credential_identifiers` * Parameter Usage Location: token response * Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net * Reference: (#token-response) of this specification +## OAuth Authorization Server Metadata Registry + +This specification registers the following authorization server metadata parameter +in the IANA "OAuth Authorization Server Metadata" registry [@IANA.OAuth.Parameters] +established by [@!RFC8414]. + +### pre-authorized_grant_anonymous_access_supported + +* Metadata Name: `pre-authorized_grant_anonymous_access_supported` +* Metadata Description: Boolean indicating whether Credential Issuer accepts Token Request with Pre-Authorized Code but without `client_id` +* Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net +* Reference: (#as-metadata) of this specification + ## OAuth Dynamic Client Registration Metadata Registry -This specification registers the following client metadata name in the IANA "OAuth Dynamic Client Registration Metadata" registry [@!IANA.OAuth.Parameters] established by [@!RFC7591]. +This specification registers the following client metadata parameter +in the IANA "OAuth Dynamic Client Registration Metadata" registry [@IANA.OAuth.Parameters] +established by [@!RFC7591]. + +### credential_offer_endpoint -* Client Metadata Name: credential_offer_endpoint +* Client Metadata Name: `credential_offer_endpoint` * Client Metadata Description: Credential Offer Endpoint * Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Reference: (#credential-offer-endpoint) of this specification - +* Reference: (#client-metadata) of this specification ## Well-Known URI Registry -This specification registers the following well-known URI in the IANA "Well-Known URI" registry established by [@!RFC5785]. +This specification registers the following well-known URI +in the IANA "Well-Known URI" registry [@IANA.OAuth.Parameters] +established by [@!RFC5785]. -* URI suffix: openid-credential-issuer +### .well-known/openid-credential-issuer + +* URI suffix: `openid-credential-issuer` * Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Specification document: (#credential-issuer-wellknown) of this document +* Specification document: (#credential-issuer-wellknown) of this specification * Related information: (none) ## Media Types Registry -This specification registers the following media types in the IANA "Media Types" registry [@!IANA.MediaTypes] in the manner described in [@!RFC6838]. +This specification registers the following media type [@RFC2046] +in the IANA "Media Types" registry [@IANA.MediaTypes] +in the manner described in [@RFC6838]. + +### application/openid4vci-proof+jwt * Type name: `application` * Subtype name: `openid4vci-proof+jwt` @@ -2237,6 +2400,19 @@ This specification registers the following media types in the IANA "Media Types" * Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net * Provisional registration? No +## Uniform Resource Identifier (URI) Schemes Registry + +This specification registers the following URI scheme +in the IANA "Uniform Resource Identifier (URI) Schemes" registry [@IANA.URI.Schemes]. + +### openid-credential-offer + +* URI Scheme: openid-credential-offer +* Description: Custom scheme used for credential offers +* Status: Permanent +* Well-Known URI Support: - +* Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net +* Reference: (#client-metadata-retrieval) of this specification # Use Cases @@ -2290,6 +2466,15 @@ The technology described in this specification was made available from contribut [[ To be removed from the final specification ]] + -15 + + * remove `claims` parameter from ISO mdoc and SD-JWT VC Credential Request + * credential response always returns an array when not returning a transaction_id with the option for additional meta-data + * deferred credential response always returns an array (same as credential response) + * notification_id is now used for an issuance flow that can contain more than one credential + * Fixed #375: Enabled non-breaking extensibility. + * Fixed #239: Completed IANA Considerations section. + -14 * removes CWT proof type @@ -2305,6 +2490,8 @@ The technology described in this specification was made available from contribut * Define Credential Dataset as a term * Define Credential Configuration as a term * remove use of the `authorization_pending` and `slow_down` error codes + * removed `c_nonce` and `c_nonce_expires_in` from the token endpoint response + * added a Nonce Endpoint where a Client can acquire a fresh c_nonce value without the overhead of a full Credential Request -13 diff --git a/overview simplified.puml b/overview simplified.puml deleted file mode 100644 index ff1446bd..00000000 --- a/overview simplified.puml +++ /dev/null @@ -1,52 +0,0 @@ -@startuml - -actor User as U -participant Wallet as W -box Issuer -participant "Server Metadata" as metadata -participant "Nonce Endpoint" as init -participant "Pushed Authorization Endpoint" as PAR -participant "Authorization Endpoint" as AS -participant "Token Endpoint" as T -participant "Credential Endpoint" as P -participant "Deferred Credential" as I -end box -autoactivate on -hide footbox - -U -> W: interact -note over W: Wallet discovers input material\nrequired to request issuance\nof a certain credential (Optional) - -W -> metadata: (OPTIONAL) get credential manifests -return credential manifests - -W -> init: (OPTIONAL) get_presentation_nonce -return p_nonce - -W -> W: (OPTIONAL) prepare presentations (bound to presentation_nonce) -deactivate W - -W -> PAR: (OPTIONAL) authorize (claims [determines credential types], (opt) vp_token, ...) - -return request_uri - -W -> AS: authorize (claims [determines credential types], (opt) vp_token, ... OR request_uri) - -note over AS: Issuer will authenticate user or utilize credentials or assertions to identify user. \noptions: local login, callback to wallet (OIDC4VPs), federated login (via OpenID or SAML), ... - -AS -> W: (OPTIONAL) request credential presentations -return vp_token - -return code - -W -> T: token (code, ...) -return access_token, id_token(, c_nonce) - -W->P: credentials (access_token, type, did, proof) - -return credential or acceptance_token(, c_nonce) - -W->I: deferred credential request (acceptance_token) -return credential - -@enduml \ No newline at end of file diff --git a/table.md b/table.md deleted file mode 100644 index 15e89931..00000000 --- a/table.md +++ /dev/null @@ -1,16 +0,0 @@ - - \ No newline at end of file