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

Torsten Lodderstedt torsten at lodderstedt.net
Mon Aug 20 07:59:44 UTC 2018

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.


kind regards,

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3872 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180820/7404e23f/attachment-0001.p7s>

More information about the Openid-specs-fapi mailing list