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

Daniel Fett fett at danielfett.de
Sun Jun 7 13:33:48 UTC 2020


Excellent points, we need to say something about metadata and discovery.

I also found that not all clients support the "infix"-type RFC8414 OAuth
server discovery document URLs (Issuer https://example.com/foo/bar
→Metadata URL
https://example.com*/.well-known/oauth-authorization-server/*foo/bar)
and that the "postfix" style seems to be perceived as the default
(Issuer https://example.com/foo/bar →Metadata URL
https://example.com/foo/bar*/.well-known/oauth-authorization-server*)
although RFC8414 says otherwise.

If we want on-the-wire interop, we need to give more guidance on this.

Does anybody have specific experience with this from practice?

-Daniel

Am 07.06.20 um 15:18 schrieb Stuart Low:
> What about discovery documents? Are these in scope?
>
> Wondering if we should be aligning
> to 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
>> <mailto: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
>> <mailto:torsten at lodderstedt.net>>
>> *Sent:* Saturday, June 6, 2020 10:09:22 AM
>> *To:* Ralph Bragg <ralph.bragg at raidiam.com
>> <mailto:ralph.bragg at raidiam.com>>
>> *Cc:* Financial API Working Group List
>> <openid-specs-fapi at lists.openid.net
>> <mailto: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
>>> <mailto: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
>>> <mailto:openid-specs-fapi-bounces at lists.openid.net>> on behalf of
>>> Torsten Lodderstedt via Openid-specs-fapi
>>> <openid-specs-fapi at lists.openid.net
>>> <mailto:openid-specs-fapi at lists.openid.net>>
>>> *Reply to: *Financial API Working Group List
>>> <openid-specs-fapi at lists.openid.net
>>> <mailto: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
>>> <mailto:openid-specs-fapi at lists.openid.net>>
>>> *Cc: *Torsten Lodderstedt <torsten at lodderstedt.net
>>> <mailto: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
>>>     <mailto: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
>>>     <mailto: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
>> <mailto: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/a6f1b656/attachment-0001.html>


More information about the Openid-specs-fapi mailing list