-
Notifications
You must be signed in to change notification settings - Fork 6
Adds requirements regarding Issuance flow with external Authorization Servers #65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Adds requirements regarding Issuance flow with external Authorization Servers #65
Conversation
|
|
||
| **Requirement: DIIP-compliant [[ref: Wallet]]s MUST NOT assume the [[ref: Authorization Server]] is on the same domain as the [[ref: Issuer]].** | ||
|
|
||
| **Requirement: If the [[ref: Authorization Server]] is a separate entity, then DIIP-compliant [[ref: Issuer]]s MUST include the `issuer_state` parameter in the Credential Offer during the *Authorization Code Flow*.** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an implementation detail between the issuer and authorization server, and i see no need to standardize/require this. If you as an issuer want to work with an external authorization, you need to arrange with the authorization server how you can link the offer back to the issuance session
|
|
||
| **Requirement: If the [[ref: Authorization Server]] is a separate entity, then DIIP-compliant [[ref: Issuer]]s MUST include the `issuer_state` parameter in the Credential Offer during the *Authorization Code Flow*.** | ||
|
|
||
| **Requirement: If the [[ref: Authorization Server]] is a separate entity, then DIIP-compliant [[ref: Authorization Server]]s MUST issue Access Tokens as JWTs, compliant with the [[ref: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens]]. The `issuer_state` value that it received via the Authorization Request from the [[ref: Wallet]] MUST be included as a claim in the Access Token JWT.** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, this is something that can be decided on a case by case basis. It makes sense for most deployments, but if an issuer and authorization server decide to do it differently it has 0 impact on interoperability. I don't think this should be a requirement
|
|
||
| **Requirement: If the [[ref: Authorization Server]] is a separate entity, then DIIP-compliant [[ref: Authorization Server]]s MUST issue Access Tokens as JWTs, compliant with the [[ref: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens]]. The `issuer_state` value that it received via the Authorization Request from the [[ref: Wallet]] MUST be included as a claim in the Access Token JWT.** | ||
|
|
||
| **Requirement: If the [[ref: Authorization Server]] is a separate entity, then DIIP-compliant [[ref: Issuer]]s MUST issue the `pre-authorized_code` as a JWT when using the *Pre-Authorized Code Flow*. This JWT MUST be signed by the [[ref: Issuer]] and MUST contain the `issuer_state` as a claim. The [[ref: Authorization Server]] MUST validate this JWT and then include the extracted `issuer_state` into the Access Token JWT it issues to the [[ref: Wallet]].** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again not sure why we this, this seems like implementation details and not relevant to the interoperability between the wallet and issuer.
(reopened from #64)
As described in #62.
This PR also includes some editorial fixes that where added to the
spec.mdfile in #57, but where not included to theindex.htmlfile yet