Encrypting NameID's and Signing Logout Messages

[Nate Klingenstein]

> That's potentially pretty significant in some systems, but there's not much risk when the client stores the session that matches, you can't just log somebody else out like you can if the state is on the server.

There's a lot more automatic saving by applications using long forms that happens now as well.

> It happens that systems deciding to ignore that part of the standard often tend to rely on NameIDs containing publically guessable values.

I thought of this before writing the message.  If everyone just used transientId's, that is effectively a secret key between the IdP and SP transmitted in the encrypted response, and the problem basically disappears.

> Encryption is really a separate issue, and it's obviously the reason I'm just done with NameIDs.

I thought there were more reasons than that.

> The primary argument is that once you demonstrate you don't pay attention to the standard, the chances of you caring about any of the standard start approaching zero.

The relevant line in the standard is 4.4.3.1 in the SLO profile, I suppose, which says that for asynchronous logout:

"The <LogoutRequest> message MUST be signed if the HTTP POST or Redirect binding is used."

So far, I have one "it's an ugly situation", one "break yer bones", and one "null".

Barring further points, I'll probably leave it at requiring signatures especially because there are apparently a lot of libraries being written or used with SAMLtest.  I'd estimate only 25% of the transactions are with a Shibboleth provider.