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

Brian Campbell bcampbell at pingidentity.com
Wed Aug 22 15:24:13 UTC 2018


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/730a5d00/attachment-0001.html>


More information about the Openid-specs-fapi mailing list