<div dir="ltr"><div dir="ltr"><div>Agreed that encrypting the logout token that's to be sent over HTTPS directly from OP to RP doesn't seem particularly useful. <br></div><div><br></div><div>That said, the issuer and audience could be conveyed in the JWE header. RFC 7519 kinda anticipated this kind of situation: <a href="https://tools.ietf.org/html/rfc7519#section-5.3">https://tools.ietf.org/html/rfc7519#section-5.3</a><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 22, 2018 at 11:29 AM Hans Zandbelt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">I believe that requiring mutual TLS would hinder adoption, certainly on the RP side since your average RP may not terminate TLS. And also if they do it is typically just cumbersome or impossible to interwork with a different layer and configure client cert validation. Making it optional would be nice. The DoS risk is about the same as on other OAuth 2.0 endpoints IMHO.<div><br></div><div>I tend to agree that encryption may not be that useful and could be left out, some text should change, especially in:</div><div><a href="https://openid.net/specs/openid-connect-backchannel-1_0.html#Validation" target="_blank">https://openid.net/specs/openid-connect-backchannel-1_0.html#Validation</a><br><div>and also the overall suggestion that logout_token validation resembles id_token validation becomes a bit of a stretch considering the list of constraints then.</div><div><br></div><div>Hans.<br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 22, 2018 at 6:33 PM Phil Hunt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Mutual tls (non tokenized) seems like a good solution provided the logout event node can use the OP’s issuer cert as client cert to establish the TLS connection. But this might not be easy for some microservice architectures as this means wider shared access to issuer private keys are needed which weakens overall security. <div><br></div><div>Regarding encrypted events...</div><div>I don’t see the value in encrypting logout events. The logout event only contains identifiers that are transitory and are now end of life notices. The primary risk is an attacker serving fake logouts as part of a DoS attack. Signed logouts plus TLS transport should be enough here. </div><div><br></div><div>We must also consider the general load on resource servers if they have to do a lot of crypto to reject false events. This is a DoS risk. Is Mutual TLS a good way to mitigate this or does it just shift the load to tls terminators? </div><div><br></div><div><div id="m_8604412758946056639m_-7958236425691035129m_-4721814092752877090AppleMailSignature">Phil</div><div><br>On Sep 22, 2018, at 8:53 AM, Tom Jones <<a href="mailto:thomasclinganjones@gmail.com" target="_blank">thomasclinganjones@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="auto">Wouldn't it make more sense for all back channel connex to be over tls with mutual auth?<br><br><div data-smartmail="gmail_signature">thx ..Tom (mobile)</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 21, 2018, 8:38 AM Phil Hunt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Interesting. My assumption is iss, aud etc are req’d claims from JWT. <br>
<br>
However maybe a reminder is important?<br>
<br>
Phil<br>
<br>
> On Sep 21, 2018, at 4:52 AM, Hans Zandbelt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
> <br>
> New issue 1049: backchannel logout requests should include a reference to the OP<br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_openid_connect_issues_1049_backchannel-2Dlogout-2Drequests-2Dshould-2Dinclude&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=lm9I-tIhoNwvye6UOWEMPW8NY3NHLUhJ9SotrZMkfjo&s=3LFWnJR17VF0dS5xSTSpiGzBJQ6AFN3Pu3Oa8M3ONMQ&e=" rel="noreferrer noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_openid_connect_issues_1049_backchannel-2Dlogout-2Drequests-2Dshould-2Dinclude&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=lm9I-tIhoNwvye6UOWEMPW8NY3NHLUhJ9SotrZMkfjo&s=3LFWnJR17VF0dS5xSTSpiGzBJQ6AFN3Pu3Oa8M3ONMQ&e=</a><br>
> <br>
> Hans Zandbelt:<br>
> <br>
> Whilst taking a stab at implementing backchannel logout according to:<br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=lm9I-tIhoNwvye6UOWEMPW8NY3NHLUhJ9SotrZMkfjo&s=L6lYaopVVDpj0Pk2gtvli2CrojHXip4pHWm-fsGlHyQ&e=" rel="noreferrer noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=lm9I-tIhoNwvye6UOWEMPW8NY3NHLUhJ9SotrZMkfjo&s=L6lYaopVVDpj0Pk2gtvli2CrojHXip4pHWm-fsGlHyQ&e=</a><br>
> <br>
> I found that for an RP that connects to multiple OPs it would be impossible to deduct the OP from the `logout_token` if it is encrypted with a symmetric key. Since following the OpenID Connect `id_token` guidelines (as suggested) it would have to decrypt with the `client_secret` which is (hopefully) a per-provider setting. Trying all OPs/`client_secret`'s consecutively would be very inefficient and probably not what anyone would want to do.<br>
> <br>
> I suggest to add an `iss` parameter to the backchannel logout request in addition to the `logout_token` parameter. <br>
> <br>
> This will also make it easier for implementors to share the code path with `id_token` validation since they'd no longer have to "peek" into the `id_token` before calling the validation routine that may be issuer specific. The issuer would typically be known before validating the id_token since it is recorded in the (browser bound) state.<br>
> <br>
> <br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=lm9I-tIhoNwvye6UOWEMPW8NY3NHLUhJ9SotrZMkfjo&s=QFeT_kOuXhKRo7gZWzW_kdBxaAC_PCO1A2u3BadpGqo&e=" rel="noreferrer noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=lm9I-tIhoNwvye6UOWEMPW8NY3NHLUhJ9SotrZMkfjo&s=QFeT_kOuXhKRo7gZWzW_kdBxaAC_PCO1A2u3BadpGqo&e=</a><br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=FD3sdo7UYTo8Q7XbmdDTGUOKlLvVI2B8koxVa-b6G2E&s=VKqLOiCGCgwXjtCAoUsFj75tPp-nU-KYNp4i40HlMSM&e=" rel="noreferrer noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
</div></blockquote></div></div>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_8604412758946056639m_-7958236425691035129gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div style="font-size:small"><a href="mailto:hans.zandbelt@zmartzone.eu" target="_blank">hans.zandbelt@zmartzone.eu</a></div><div style="font-size:small">ZmartZone IAM - <a href="http://www.zmartzone.eu" target="_blank">www.zmartzone.eu</a><br></div></div></div></div></div></div></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.</font></span></i>