[Openid-specs-fapi] JWT Secured Authorization Response Mode (#155)

Filip Skokan panva.ip at gmail.com
Wed Aug 22 15:25:30 UTC 2018


Absolutely agreed.

Best,
*Filip*


On Wed, Aug 22, 2018 at 5:24 PM Brian Campbell <bcampbell at pingidentity.com>
wrote:

> Yeah, an asymmetric JWE doesn't give any assurances of message integrity
> from the sender.  Given that the main thrust of the draft is securing
> (where that mostly means integrity protection in this context) the
> authorization response, I think it's best to leave the requirement of a JWS
> with an actual signature/MAC for the response. I mean, the draft could
> conceivably allow the response JWT to be just/only a JWE when symmetric
> encryption is used because both confidentiality and integrity are provided
> by the AEADness of it. But I think that for the purposes of this draft,
> it's not worth the added complexity / subtitles and its more straight
> forward to just keep it as it is where a JWS signature is always needed and
> that can optionally be enclosed in a JWE.
>
> On Wed, Aug 22, 2018 at 1:27 AM Filip Skokan <panva.ip at gmail.com> wrote:
>
>> Hmm, you're right, should the client's public keys be exposed via
>> jwks_uri then anyone can encrypt a message. Strike my last then.
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Wed, Aug 22, 2018 at 9:25 AM Torsten Lodderstedt <
>> torsten at lodderstedt.net> wrote:
>>
>>>
>>>
>>> > Am 22.08.2018 um 07:34 schrieb Filip Skokan <panva.ip at gmail.com>:
>>> >
>>> > The point about encryption makes sense.
>>> >
>>> > If a payload is encrypted for the receiving party, could JWS none be
>>> used then?
>>>
>>> What would be the rationale?
>>>
>>> >
>>> > Filip
>>> >
>>> > Odesláno z iPhonu
>>> >
>>> > 21. 8. 2018 v 23:57, Brian Campbell <bcampbell at pingidentity.com>:
>>> >
>>> >> Thanks Filip, we'll try and ensure this makes it into the document.
>>> >>
>>> >> On Tue, Aug 21, 2018 at 2:52 PM Filip Skokan <panva.ip at gmail.com>
>>> wrote:
>>> >> my $.02, drawing from
>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>>> >>
>>> >> query.jwt response mode use with implicit and hybrid response types
>>> should have the same restriction as regular query does => MUST NOT be used.
>>> >>
>>> >> Agree. Unless the response JWT is encrypted, in which case it's okay
>>> I think.
>>> >>
>>> >> fragment.jwt while weird for code flow, does not need this
>>> restriction.
>>> >>
>>> >> Also agree.
>>> >>
>>> >>
>>> >> Best,
>>> >> Filip
>>> >>
>>> >>
>>> >> On Tue, Aug 21, 2018 at 9:58 PM Torsten Lodderstedt <
>>> torsten at lodderstedt.net> wrote:
>>> >> Hi Brian,
>>> >>
>>> >> > Am 20.08.2018 um 22:59 schrieb Brian Campbell <
>>> bcampbell at pingidentity.com>:
>>> >> >
>>> >> > Thanks, Torsten, for all your work and the quick updates on this.
>>> I've got the few more comments (from a not necessarily comprehensive
>>> review) below but the comments are getting more and more nitpicky rather
>>> than substantial, which to me means it's getting close to being ready.
>>> >>
>>> >> Great!
>>> >>
>>> >> >
>>> >> > [RFC6750] & [RFC7636], are used "2. Terms and definitions" but
>>> aren't in the "1. Normative references“
>>> >>
>>> >> Fixed.
>>> >>
>>> >> >
>>> >> > When FAPI is expanded anywhere it should now be Financial-grade
>>> API, no?
>>> >>
>>> >> Changed.
>>> >>
>>> >> >
>>> >> > I think it might be worthwhile to have a §4.1.3 that more generally
>>> speaks to other response types (like the various combinations from OIDM).
>>> It wouldn't have to cover them all specifically but maybe just say
>>> something to the effect of all authorization endpoint response parameters
>>> are conveyved as claims/parameters of the JWT. The way it is now with
>>> §4.1.1 for code and §4.1.2 for token kinda sorta suggest that those two are
>>> all that's supported. I realize other parts of the document say otherwise
>>> but I can see it being a point of confusion.
>>> >>
>>> >> Tried to incorporate this into 4.1.
>>> >>
>>> >> >
>>> >> > I wonder if the "jwt" shortcut mode is worthwhile to have or if
>>> it's better to have the client simply be explicit about it using?
>>> >>
>>> >> My feeling is the shortcut is more robust than the explicit values as
>>> it always defaults to a legal/generally accepted value for the particular
>>> response type.
>>> >>
>>> >> Just to give some example of „weird" combinations:
>>> >> „query.jwt" and „token“ can only be used with caution.
>>> >> Does „fragment.jwt" and „code“ make any sense?
>>> >>
>>> >> > I'm not sure I have a strong opinion about it but just wanted to
>>> raise the question. If it's kept, the defaults should probably also speak
>>> to the other response types from OIDM (default for code alone is query and
>>> everything else is fragment).
>>> >>
>>> >>
>>> >>
>>> >> >
>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Combinations
>>> spells it out and maybe a reference with context of the jwt.fragment where
>>> fragment is used in OIDM and jwt.qurery where qurey is used in OIDM would
>>> work.
>>> >>
>>> >> Generalized 4.3.4 and added reference to OIDM
>>> >>
>>> >> >
>>> >> > Probably it should also say somewhere that jwt.query encoding must
>>> not be used for response types that contain "token" or "id_token" so as to
>>> avoid leakage etc from having those things in the URL. Unless the JWT
>>> response is encrypted, in which case it would be okay.
>>> >>
>>> >> Added some text.
>>> >>
>>> >> >
>>> >> > In 4.4: Maybe change "The key might be a private key registered
>>> with the expected issuer of the response "to  "The key might be a private
>>> key, where the corresponding public key is registered with the expected
>>> issuer of the response" or something like that just to be clear about what
>>> part of the key is used for what.
>>> >>
>>> >> adopted
>>> >>
>>> >> >
>>> >> > Also in 4.4 change "determine" to "determined" and "neede" to
>>> „needed"
>>> >>
>>> >> fixed.
>>> >>
>>> >> >
>>> >> > Given that 4.4 is calling out checks on iss and aud, it should
>>> maybe also say to check the exp. That's already implied by JWT in general
>>> but seems maybe worth calling out in the processing rules along with the
>>> other checks.
>>> >>
>>> >> added exp check
>>> >>
>>> >> >
>>> >> >
>>> >> > In "5. Client Metadata" and/or somewhere else in the doc, should
>>> the JWS "none" alg be prohibited?
>>> >>
>>> >> added sentence
>>> >>
>>> >> >
>>> >> > In §5 and §6 JWS [RFC7515] is used but 7515 isn't in the
>>> references.
>>> >>
>>> >> added RFC7515 to references.
>>> >>
>>> >> Latest version can be found at
>>> https://bitbucket.org/openid/fapi/src/155-JWT-Secured-Authorization-Response-Mode/Financial_API_JWT_Secured_Authorization_Response_Mode.md
>>> >>
>>> >> kind regards,
>>> >> Torsten.
>>> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Mon, Aug 20, 2018 at 1:59 AM Torsten Lodderstedt via
>>> Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
>>> >> > Hi Filip,
>>> >> >
>>> >> > good point! I added text on extension parameters.
>>> >> >
>>> >> > I also added an IANA Consideration section (registration of new
>>> client registration and server metadata parameters) and text on publication
>>> of supported response mode values.
>>> >> >
>>> >> >
>>> https://bitbucket.org/openid/fapi/src/155-JWT-Secured-Authorization-Response-Mode/Financial_API_JWT_Secured_Authorization_Response_Mode.md
>>> >> >
>>> >> > kind regards,
>>> >> > Torsten.
>>> >> >
>>> >> > > Am 19.08.2018 um 19:27 schrieb Filip Skokan <panva.ip at gmail.com>:
>>> >> > >
>>> >> > > Hello Torsten,
>>> >> > >
>>> >> > > Some specs, e.g. session management define additional
>>> authorization endpoint response parameters (session_state in case of
>>> session management).
>>> >> > > It’d be great to define if these additional params belong in the
>>> jwt or are sent using the regular response mode.
>>> >> > >
>>> >> > > Best,
>>> >> > > Filip
>>> >> > >
>>> >> > > Odesláno z iPhonu
>>> >> > >
>>> >> > > 19. 8. 2018 v 17:47, Torsten Lodderstedt via Openid-specs-fapi <
>>> openid-specs-fapi at lists.openid.net>:
>>> >> > >
>>> >> > >> Hi all,
>>> >> > >>
>>> >> > >> I incorporated Brian’s and Vladimir’s comments/proposals.
>>> >> > >>
>>> >> > >> Here is a list of the changes:
>>> >> > >> - moved state into the JWT
>>> >> > >> - adopted processing rules to logic as defined below
>>> >> > >> - added response mode values to be able to distinguish query,
>>> fragment and form post encoding
>>> >> > >> - added form post encoding
>>> >> > >> - added client and server metadata
>>> >> > >>
>>> >> > >> Take a look:
>>> https://bitbucket.org/openid/fapi/src/155-JWT-Secured-Authorization-Response-Mode/Financial_API_JWT_Secured_Authorization_Response_Mode.md
>>> >> > >>
>>> >> > >> Looking forward for your feedback.
>>> >> > >>
>>> >> > >> kind regards,
>>> >> > >> Torsten.
>>> >> > >>
>>> >> > >>> Am 17.08.2018 um 19:24 schrieb Brian Campbell <
>>> bcampbell at pingidentity.com>:
>>> >> > >>>
>>> >> > >>> Yeah, I think that captures the general processing flow.
>>> >> > >>>
>>> >> > >>> On Fri, Aug 17, 2018 at 8:50 AM Torsten Lodderstedt <
>>> torsten at lodderstedt.net> wrote:
>>> >> > >>> Hi Brian,
>>> >> > >>>
>>> >> > >>>> Am 17.08.2018 um 15:39 schrieb Brian Campbell <
>>> bcampbell at pingidentity.com>:
>>> >> > >>>>
>>> >> > >>>> Good point. OIDC Core (
>>> http://openid.net/specs/openid-connect-core-1_0.html#Security) does not
>>> discuss this attack angle. From your perspective, what is the typical way
>>> to detect crafted/modified ID Tokens in the id_token flow?
>>> >> > >>>>
>>> >> > >>>> Checking the signature. But if the issuer isn't known or
>>> expected, don't go trying to find keys for it, just reject the token.
>>> >> > >>>
>>> >> > >>>
>>> >> > >>> I would like to summarize the discussion regarding handling of
>>> state value and response processing.
>>> >> > >>>
>>> >> > >>> From what I understand, the processing would work as follows
>>> (assuming the „state" is carried in the JWT):
>>> >> > >>>
>>> >> > >>> 1) decrypt JWT using the client's private key - the key is
>>> determine by the „kid“ header parameter
>>> >> > >>> 2) obtain „state“ from JWT
>>> >> > >>> 3) check binding of state value to user agent, if check fails -
>>> abort processing
>>> >> > >>> 4) obtain „iss" from JWT
>>> >> > >>> 5) check whether „iss" is known and expected („aud“ could be
>>> checked in this step as well), if not abort processing
>>> >> > >>> 6) obtain signing key based on „iss“ and „kid"
>>> >> > >>> 7) check signature, if signature validation fails - abort
>>> processing
>>> >> > >>> 8) use response parameters
>>> >> > >>>
>>> >> > >>> Does this capture your thoughts correctly?
>>> >> > >>>
>>> >> > >>> Kind regards,
>>> >> > >>> Torsten.
>>> >> > >>>
>>> >> > >>> CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited.
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.
>>> >> > >>
>>> >> > >> _______________________________________________
>>> >> > >> 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
>>> >> >
>>> >> > CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited.
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.
>>> >>
>>> >>
>>> >> CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited.
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.
>>>
>>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180822/d8ac074d/attachment-0001.html>


More information about the Openid-specs-fapi mailing list