RFC018: Issuing credentials using OIDC4VCI #257
Conversation
reinkrul
changed the title
|
|
||
| ### Status of document | ||
|
|
||
| This document describes a Nuts standards protocol. |
why? |
Otherwise it's not a Nuts node, just a half one. |
| 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: |
There was a problem hiding this comment.
"does not need" might be too vague.
Are all the items in the list restricted by what's advertised in the (wallet/issue) metadata? If not then the does not becomes a must not?
There was a problem hiding this comment.
Then you can't have a generic OpenID4VCI wallet that also support Nuts, since a compelte implementation vs this RFC are mutually exclusive.
Maybe we should inverse it, specifying what MUST be supported? Although I wrote it up this way since that sounded easier.
There was a problem hiding this comment.
Usually I scan to see what I MUST do and skip everything else ;)
|
|
||
| ### 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`. |
There was a problem hiding this comment.
You mean retrieve within the context of the offer call? Not async
There was a problem hiding this comment.
No, just whether the wallet accepted the credential offer. I'll clarify the sentence.
| 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 |
There was a problem hiding this comment.
I think I tried to convey that we only trust issuers from trusted certificates, which is defined by the truststore. And since identifier URLs are HTTPS URLs, they're trusted if the connection can be made.
| - Pre-authorized code flow | ||
| - Credential offer: | ||
| - with `credential_offer` parameter | ||
| - with `string` values, referring to a credential's `id` in `credentials_supported` |
There was a problem hiding this comment.
We currently do not support this since our credential definitions do not contain an id? @woutslakhorst
There was a problem hiding this comment.
For the credentials array I think we only support the JSON object containing the ldp_vc format specific credential_definition as defined for in https://openid.bitbucket.io/connect/editors-draft/openid-4-verifiable-credential-issuance-1_0.html#name-vc-secured-using-data-integ
There was a problem hiding this comment.
Recent versions of the spec seem to have replaced id by scope. The scope field is also not present in our definitions. Not sure if the node or this RFC should be changed?
|
|
||
| ### 3.2.1 Credential Offer Success Response | ||
|
|
||
| In case the wallet considers the offer valid, it MUST respond with HTTP status `200 OK`. |
There was a problem hiding this comment.
Just to check, we still need to implement this right?
There was a problem hiding this comment.
This conflicts with the synchronous flow. An invalid credential in the synchronous flow for a valid offer would result in a 400 while this line says that it MUST be a 200. A better separation between sync/async flow should fix this
There was a problem hiding this comment.
It says when it is considered valid? So if valid, 200, if not 400.
The sync part will probably change when we support retying.
There was a problem hiding this comment.
I guess it depends on what you consider to be "the offer". My interpretation was that this is just the credential_offer message, but seems that you refer to the entire flow which includes retrieval of the credential for the sync flow.
|
We're not going to support this as it currently is. Keeping branch for future reference. |
TODO:
Fixes #258