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

Nat Sakimura sakimura at gmail.com
Sat Mar 25 19:24:11 UTC 2017


So, Axel, what do you think about " use the URI that the client publishes
for its backchannel endpoint as the audience rather than the client ID."?

On Wed, Mar 22, 2017 at 4:21 AM Axel Nennker via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> 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.
>
>
>
> //Axel
>
>
>
>
>
>
>
> *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> 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); 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" <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 <+49%20170%202275312> (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
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170325/0861e27f/attachment-0001.html>


More information about the Openid-specs-ab mailing list