add require_interactive_authorization_requests to AS metadata #615
Conversation
awoie
requested review from
Sakurann,
bc-pi,
c2bo,
charsleysa,
jogu,
paulbastian and
tplooker
awoie
force-pushed
the
awoie/fix-604
branch
2 times, most recently
from
f0e4cde to
643fa99
Compare
|
Discussed on today's WG call; Raj offered to review, Paul to re-review. |
|
|
||
| * `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`. | ||
| * `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`. | ||
| * `interactive_authorization_endpoint`: OPTIONAL. URL of the Authorization Server's Interactive Authorization Endpoint. This URL MUST use the https scheme and MAY contain port, path, and query parameter components. If omitted, the Authorization Server does not support the Interactive Authorization Endpoint. If present, the Wallet SHOULD use this endpoint to obtain authorization as defined in (#interactive-authorization-endpoint). |
There was a problem hiding this comment.
Shouldn't the AS metadata also declare the interaction_types_required or interaction_types_supported? The pattern that the Wallet is sending interaction_types_supported seems uncommon to OAuth from my perspective. I would appreciate that as some form of authentication negotiation over the AS metadata
There was a problem hiding this comment.
Yep, this was discussed here #598 but we decided that a dedicated error code is sufficient. We could add an AS metadata for this in the future. IMO, a separate issue. You could ask to reopen the issue if you think this feature is required.
|
may not be directly related to this PR, but I think if we touch the AS metadata in this PR it should be complete. Was this previously discussed? |
| * `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`. | ||
| * `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`. | ||
| * `interactive_authorization_endpoint`: OPTIONAL. URL of the Authorization Server's Interactive Authorization Endpoint. This URL MUST use the https scheme and MAY contain port, path, and query parameter components. If omitted, the Authorization Server does not support the Interactive Authorization Endpoint. If present, the Wallet SHOULD use this endpoint to obtain authorization as defined in (#interactive-authorization-endpoint). | ||
| * `require_interactive_authorization_requests`: OPTIONAL. A boolean indicating whether the Authorization Server accepts Authorization Request that request Credential issuance only via the Interactive Authorization Endpoint defined in (#interactive-authorization-endpoint). If omitted, the default value is `false`. This parameter MUST NOT be present if `interactive_authorization_endpoint` is omitted. Note that the presence of `interactive_authorization_endpoint` is sufficient for a Wallet to determine that it can use the Interactive Authorization Endpoint. |
There was a problem hiding this comment.
We have a SHOULD recommendation, that IAE is preferred over normal auth endpoint. Shouldn't the default value be true then?
There was a problem hiding this comment.
The SHOULD recommendation helps wallets to decided whether to use the authorization_endpoint or the interactive_authorization_endpoint whereas the require_interactive_authorization_requests just says that this is the only option. The semantics are different and not entirely related.
Yes, see above (#598) |
deshmukhrajvardhan
left a comment
deshmukhrajvardhan
left a comment
There was a problem hiding this comment.
Few editorial comments. The content and general direction looks good to me.
|
WG discussion:
|
Additionally, and as an editorial change, I added interactive_authorization_endpoint to the AS metadata section, as it was previously missing. I also moved the corresponding normative "SHOULD use the IAE" statement into the AS metadata section, for consistency with how other endpoints are handled.
|
I've updated this to apply to 1.1 spec |
Fixes #604
Additionally, and as an editorial change, I added
interactive_authorization_endpointto the AS metadata section, as it was previously missing. I also moved the corresponding normative "SHOULD use the IAE" statement into the AS metadata section, for consistency with how other endpoints are handled.