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

Wed Aug 22 07:27:10 UTC 2018

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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180822/b7f3be5b/attachment-0001.html>