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

[John Bradley]

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> wrote:
> 
> +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 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
>>  
>> Hi,
>>  
>> Regarding https://openid.net/specs/openid-connect-backchannel-1_0.html <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 <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 <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
>> 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 <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>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab <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/20170317/b7bc67f9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4383 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170317/b7bc67f9/attachment.p7s>