This is new!

I must have missed the memo on unencrypted tokens… will check with the OSIS crowd and report back – this will most likely temporarily break some Relying Parties (including mine). Oh, the wicked pace of progress :)

Usually these things are encrypted

10 thoughts on “This is new!

  1. That’s what I thought at first too – but apparently this has nothing to do with the HTTPS protocol — the wag site pictured above is an SSL site. It happens at my sites too, which are currently all HTTPS sites.

    In fact, I would say that the HTTP case is the one place where an encrypted token should be mandatory, since the transport is in the clear…

  2. Ah but if it’s coming over HTTP there is no certificate; so what do you encrypt against?

    And once we’re using managed cards all bets are off anyway; as an STS you don’t have to encrypt against the public SSL certificate, you could have a pre-agreed arrangement where you distribute client certificates and use those, or even ROT13 *grin*

  3. (Was this a managed card BTW? If it’s a managed card which audits, i.e. has RequiresAppliesTo then it’s up to the STS to encrypt, and that is optional)

  4. Hi Pamela – this came up at I3. I originally misconfigured our STS to not encrypt tokens. Most RPs worked ok, but some failed ( all of yours ). I looked back at the spec and unencrypted tokens seem to be allowed, so I left the STS as is, since it looked like a good test.

  5. I had originally just assumed that it was tied to the web protocol used, ie if the RP uses SSL, they get an encrypted token back, and if the RP uses NoSSL, then all bets were off.

    From the discussion on the OSIS list, it sounds like an RP needs to handle both possibilities for token encryption, regardless of whether the connection itself is encrypted. After that, it would be the administrator’s choice to reject certain types of tokens if it was a problem.

  6. Vittorio: yeah, look at me, getting all demanding :)

    I’d like to think that an RP *could* demand some level of encryption even though there is no SSL channel. To say they *must* do so is just silly.

    Maybe I’ll just get NoSSL working first, before I worry about message-level encryption schemes :)

  7. Oh and it’s a function of the managed card to decide if it supports NoSSL. If you issue a managed card with a RequireStrongRecipientIdentity parameter it won’t even light up in the selector if a non-SSL site is triggering card selection.

    Of course it’s always best to check on the STS, just in case a selector got it wrong.

    The other point to note is how then is a token tied to an RP in a no SSL/No encryption case; it has to be a site specific ID, either reflecting the client pseudonym as a PPID or constructing a site specific one of your own.

Comments are closed.