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

Filip Skokan panva.ip at gmail.com
Tue Aug 21 20:52:16 UTC 2018


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.
fragment.jwt while weird for code flow, does not need this restriction.

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


More information about the Openid-specs-fapi mailing list