[Openid-specs-fapi] FAPI 2 Advanced Profile / Recommendations for signing resource requests/responses
fett at danielfett.de
Sun Jun 7 13:10:11 UTC 2020
thanks for the feedback. Some comments below.
Am 06.06.20 um 10:35 schrieb Torsten Lodderstedt:
> Hi Daniel,
>> Am 05.06.2020 um 10:20 schrieb Daniel Fett via Openid-specs-fapi
>> <openid-specs-fapi at lists.openid.net>:
> Here are my comments:
> - „ shall support at least one of the following methods to sign the
> authorization response:“
> I think the AS must support at least one mode for interoperability
> reasons. I think this should be JARM and ID token may be supported
> (for the purpose of this profile) for backward compatibility reasons.
Good point. In the spirit of forcing on-the-wire interop, making JARM a
"shall" makes sense.
> „OPEN QUESTION: how to handle userinfo response type selection? OIDC
> core says: depends on client registration“ I think that's fine. We use
> the same philosophy for all sorts of request and response signing.
> It’s determined by client registration parameters + general deployment
> metadata (what is generally supported/expected).
Makes sense. I removed this question. I wonder if we should make the
userinfo mandatory for OIDC-supporting implementations, but I feel that
this can be left up to the implementers.
I also made fixes for the other two points that you raised. I will
upload a new version in the next minutes.
> best regards,
>> One open question is whether we can give recommendations regarding
>> resource request and response signing. We currently have
>> which lists "typical requirements" but does not give concrete advice.
>> eTSI is developding JAdES and there is some work ongoing in the IETF
>> HTTP group as well.
>> What are other options that we should take a look at?
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-fapi