[Openid-specs-ab] Two issues on id_token_hint 
ve7jtb at ve7jtb.com
Mon Nov 24 23:02:36 UTC 2014
OPTIONAL. JWS [JWS] alg algorithm [JWA] that MUST be used for signing Request Objects sent to the OP. All Request Objects from this Client MUST be rejected, if not signed with this algorithm. Request Objects are described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core]. This algorithm MUST be used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter). Servers SHOULD support RS256. The value noneMAY be used. The default, if omitted, is that any algorithm supported by the OP and the RP MAY be used.
OPTIONAL. JWE [JWE] alg algorithm [JWA] the RP is declaring that it may use for encrypting Request Objects sent to the OP. This parameter SHOULD be included when symmetric encryption will be used, since this signals to the OP that a client_secret value needs to be returned from which the symmetric key will be derived, that might not otherwise be returned. The RP MAY still use other supported encryption algorithms or send unencrypted Request Objects, even when this parameter is present. If both signing and encryption are requested, the Request Object will be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. The default, if omitted, is that the RP is not declaring whether it might encrypt any Request Objects.
OPTIONAL. JWE enc algorithm [JWA] the RP is declaring that it may use for encrypting Request Objects sent to the OP. If request_object_encryption_alg is specified, the default for this value is A128CBC-HS256. When request_object_encryption_enc is included,request_object_encryption_alg MUST also be provided.
My intent was that the client should be free to use any of the algs published in discovery. Using a key with a enc use published by the AS.
The signing is locked down to prevent downgrade attacks.
For encryption anyone can asymmetrically encrypt as the key is public, so locking it to a single alg is not required.
What else would the client be sending to the server encrypted?
> On Nov 22, 2014, at 4:59 AM, Roland Hedberg <roland.hedberg at umu.se> wrote:
> In the core spec it’s stated:
> ”The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as the id_token_hint value.”
> It’s not clear to me which algorithms that can/should be used by the client.
> In client registration, the client and server using id_token_encrypted_response_alg &
> id_token_encrypted_response_enc agrees on what to use when the server encrypts en IdToken for the client.
> There is nothing agreed on when the client is encrypting something for the server.
> That leads to two possible interpretations:
> 1) The id_token_encrypted_response_alg & id_token_encrypted_response_enc should also be used
> when the client encrypts IdTokens for the server.
> 2) The client is free to use whatever algorithms the server has published using
> id_token_encryption_alg_values_supported and id_token_encryption_enc_values_supported
> in the discovery phase given that the client has suitable keys.
> I think we should make clear which behavior we expect.
> — Roland
> ”Being able to think like a child is an important attribute of being an adult” - Eddie Izzard
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4326 bytes
Desc: not available
More information about the Openid-specs-ab