[Openid-specs-fapi] FAPI 2 Advanced Profile / Recommendations for signing resource requests/responses

[Stuart Low]

What about discovery documents? Are these in scope?

Wondering if we should be aligning to https://tools.ietf.org/html/rfc8414 <https://tools.ietf.org/html/rfc8414> and perhaps mandating Signed Metadata for Advanced?

Stu

> On 6 Jun 2020, at 7:40 pm, Ralph Bragg via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> 
> Another quick one, in the bottom Section on Cryptography and Secrets In bass line there is mention of “symmetric credentials” being permitted. But I couldn’t see anywhere in the requirements for AS that they should be supported. 
> 
> If there’s a need can it be stated? (I’ll raise a ticket). Additionally for advanced profile this clause, if it’s still required, should be assymetric only no?
> 
> Will raise a ticket on advanced for that decision as well.
> 
> From: Torsten Lodderstedt <torsten at lodderstedt.net>
> Sent: Saturday, June 6, 2020 10:09:22 AM
> To: Ralph Bragg <ralph.bragg at raidiam.com>
> Cc: Financial API Working Group List <openid-specs-fapi at lists.openid.net>
> Subject: Re: [Openid-specs-fapi] FAPI 2 Advanced Profile / Recommendations for signing resource requests/responses
>  
> I also suggest we document what metadata values AS and client are supposed to use, e.g. there will be the metadata parameter require_pushed_authorization_requests to let the AS indicate it supports pushed authorization requests only (https://mailarchive.ietf.org/arch/msg/oauth/S76ODyZkHPSA6L69yyx08BuEP5M/ <https://mailarchive.ietf.org/arch/msg/oauth/S76ODyZkHPSA6L69yyx08BuEP5M/>).
> 
> A FAPI2 compliant AS must set this value to true.
> 
>> Am 06.06.2020 um 10:55 schrieb Ralph Bragg <ralph.bragg at raidiam.com>:
>> 
>> 
>> Hi Daniel,
>>  
>> In addition to Torstens comments, and if we’re looking for backwards combability, do we care or want to mandate that the id_token from the front channel is ONLY used for code binding. Sub is a mandatory property of the id_token and as such required, to prevent any leakage of any information useful to a potential attacker should the sub property explicitly be made pairwise or some other value deliberately not related to the resource owner / subject.
>>  
>> Kind Regards,
>> Ralph
>>  
>>  
>>  
>> From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on behalf of Torsten Lodderstedt via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>
>> Reply to: Financial API Working Group List <openid-specs-fapi at lists.openid.net>
>> Date: Saturday, 6 June 2020 at 09:36
>> To: Financial API Working Group List <openid-specs-fapi at lists.openid.net>
>> Cc: Torsten Lodderstedt <torsten at lodderstedt.net>
>> Subject: Re: [Openid-specs-fapi] FAPI 2 Advanced Profile / Recommendations for signing resource requests/responses
>>  
>> Hi Daniel,
>> 
>> 
>> Am 05.06.2020 um 10:20 schrieb Daniel Fett via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>:
>> 
>> Hi all,
>> 
>> I prepared a first (rough) draft of the FAPI 2 Advanced profile and would welcome your feedback:https://bitbucket.org/openid/fapi/src/c28fc020e7ab9377d96501f2b4daa9a9da8f2128/FAPI_2_0_Advanced_Profile.md?at=danielfett%2Ffapi2%2Fadvanced <https://bitbucket.org/openid/fapi/src/c28fc020e7ab9377d96501f2b4daa9a9da8f2128/FAPI_2_0_Advanced_Profile.md?at=danielfett%2Ffapi2%2Fadvanced>
>> thanks for preparing the draft!
>>  
>> Here are my comments:
>> - [@I-D.lodderstedt-oauth-par] should refer to the WG draft
>> - „ 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.
>> „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).
>> - „The FAPI 2.0 endpoints are OAuth 2.0 protected resource endpoints that return protected information for the resource owner associated with the submitted access token.“ - RSs also initiate actions (eg payments), that’s one important reason for requiring non-repudiation. I suggest to add something like „.... that perform sensitive actions and return protected information for the resource owner ...“
>> 
>> 
>> best regards,
>> Torsten.
>> One open question is whether we can give recommendations regarding resource request and response signing. We currently have https://bitbucket.org/openid/fapi/src/master/Financial_API_HTTP_Signing.md <https://bitbucket.org/openid/fapi/src/master/Financial_API_HTTP_Signing.md> 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?
>> 
>> -Daniel
>> 
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200607/c1430f08/attachment-0001.html>