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

[Daniel Fett]

Thanks for the feedback. We don't have symmetric client auth in FAPI 2,
so that can be removed.

-Daniel

Am 06.06.20 um 11:40 schrieb Ralph Bragg:
> 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/).
>
> 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
>>
>> 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
>>     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
>>

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