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

Axel.Nennker at telekom.de Axel.Nennker at telekom.de
Wed Mar 22 09:21:36 UTC 2017

If the issuer has a id_token_signing_key and a logout_command_signing_key then the receiver knows that the JWS is not a valid signed logout_command-JSON, right?
If somebody tries to push an id_token into the logout endpoint then it would not validate because the wrong key is used.

I am not saying that different signing keys are the best solution but the proposed “solution” is hacky.


From: John Bradley [mailto:ve7jtb at ve7jtb.com]
Sent: Friday, March 17, 2017 4:55 PM
To: Justin Richer
Cc: Nennker, Axel; Michael Jones; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] backchannel logout: nonce and key

A diffrent signing key won’t help unless the issuer is different.

It is a double edged thing you want the issuer to be the same to know the logout source is the same as the login, however you don’t want the issuer to be the same to prevent the token from being mistaken as a id_token for login.

Logically it would be better to have a different logout audience for the client and change that.

One option would be to use the URI that the client publishes for its backchannel endpoint as the audience rather then the client ID.

I think William made a proposal along those lines.

John B.

On Mar 16, 2017, at 11:16 AM, Justin Richer <jricher at MIT.EDU<mailto:jricher at MIT.EDU>> wrote:


On 3/16/2017 7:58 AM, Axel Nennker via Openid-specs-ab wrote:
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

The following Claim MUST NOT be used within the Logout Token:
PROHIBITED. A nonce Claim 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<mailto:Michael.Jones at microsoft.com>); John Bradley (ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>)
Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: backchannel logout: events


Regarding https://openid.net/specs/openid-connect-backchannel-1_0.html

I am wondering what the reason behind events is:
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"<http://schemas.openid.net/event/backchannel-logout>: {}


Kind regards

T-Labs (Research & Innovation)
Dipl.-Inform. Axel Nennker
Winterfeldtstr. 21, 10781 Berlin
+491702275312 (Mobile)
E-Mail: axel.nennker at telekom.de<mailto:axel.nennker at telekom.de>


Openid-specs-ab mailing list

Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170322/f4dd1434/attachment-0001.html>

More information about the Openid-specs-ab mailing list