[Openid-specs-ab] backchannel logout: nonce and key

[Justin Richer]

+1


On 3/16/2017 7:58 AM, Axel Nennker via Openid-specs-ab wrote:
>
> Hi,
>
> Nonce in the logout JWT is prohibited to make a Logout Token 
> syntactically invalid compared to an id_token.
>
> Wouldn’t it be more secure to use another signing key than the 
> id_token signing key?
>
> Prohibiting nonce is a hack.
>
> Kind regards
>
> Axel
>
> The following Claim MUST NOT be used within the Logout Token:
>
> nonce
>
> PROHIBITED. A nonceClaim MUST NOT be present. Its use is prohibited to 
> make a Logout Token syntactically invalid if used in a forged 
> Authentication Response in place of an ID Token.
>
> Logout Tokens MAY contain other Claims. Any Claims used that are not 
> understood MUST be ignored.
>
> A Logout Token MUST be signed and MAY also be encrypted. The same keys 
> are used to sign and encrypt Logout Tokens as are used for ID Tokens. 
> NOTE: The Logout Token is compatible with Security Event Token (SET) 
> <http://openid.net/specs/openid-connect-backchannel-1_0.html#I-D.ietf-secevent-token> 
> [I‑D.ietf‑secevent‑token] draft -00.
>
> *From:*Nennker, Axel
> *Sent:* Thursday, March 16, 2017 12:49 PM
> *To:* Mike Jones (Michael.Jones at microsoft.com); John Bradley 
> (ve7jtb at ve7jtb.com)
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* backchannel logout: events
>
> Hi,
>
> Regarding https://openid.net/specs/openid-connect-backchannel-1_0.html
>
> I am wondering what the reason behind events is:
>
> events
>
> REQUIRED. Claim whose value is a JSON object containing the member 
> name http://schemas.openid.net/event/backchannel-logout. This declares 
> that the JWT is a Logout Token. The corresponding member value MUST be 
> a JSON object and SHOULD be the empty JSON object {}.
>
> The reason, I think, to have “events” is to make the logout JWT 
> compatible to SET: 
> https://tools.ietf.org/html/draft-ietf-secevent-token-01
>
> But SET states: “Security Events are not commands issued between parties”
>
> While openid-connect-backchannel-1_0.html JWT is a command.
>
> If we want SET compatibility wouldn’t it make more sense to have a SET 
> compatible response to the logout command?
>
> Why is SET compatibility important? Is it important enough to justify 
> this really strange type specifier?
>
> "events": {
>       "http://schemas.openid.net/event/backchannel-logout": {}
>       }
>
> Kind regards
>
> Axel
>
> *Deutsche Telekom AG*
>
> T-Labs (Research & Innovation)
> Dipl.-Inform. Axel Nennker
> Winterfeldtstr. 21, 10781 Berlin
> +491702275312 (Mobile)
>
> E-Mail: axel.nennker at telekom.de
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170316/7f320062/attachment.html>