{"id":686,"date":"2007-02-18T17:45:43","date_gmt":"2007-02-19T01:45:43","guid":{"rendered":"\/?p=686"},"modified":"2007-02-18T18:08:56","modified_gmt":"2007-02-19T02:08:56","slug":"what-is-meant-by-token-independence","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=686","title":{"rendered":"What is meant by “token independence”?"},"content":{"rendered":"

I don't want to get sidetracked into a discussion of the nuances the SAML protocol and token independence, but imagine readers will want me to share a comment by Scott Cantor – one of the principal creators of Shibboleth.  He knows something about SAML too – since he was the editor of the Version 2.0 spec.  He is responding to my recent post<\/a> about why communications protocol, trust system and token payload must become three orthogonal axes:<\/p>\n

SAML doesn\u00e2\u20ac\u2122t have the problem Kim is referring to either. Both trust model and token format are out of scope of SAML protocol exchanges. The former is generally understood, but the token issue is the source of a lot of FUD, or in Kim\u00e2\u20ac\u2122s case just misunderstanding SAML. This is largely SAML\u00e2\u20ac\u2122s own fault, as the specs do not explain the issue well.<\/p>\n

It is true that SAML protocols generally return assertions. What isn\u00e2\u20ac\u2122t true is that a SAML assertion in and of itself is a security token. What turns a SAML assertion into such a token is the SubjectConfirmation construct inside it. That construct is extensible\/open to any token type, proof mechanism, trust model, etc.<\/p>\n

So the difference between SAML and WS-Trust is that SAML returns other tokens by bridging them from a SAML assertion so as to create a common baseline to work from, while WS-Trust returns the other tokens by themselves. This isn\u00e2\u20ac\u2122t more or less functional, it\u00e2\u20ac\u2122s simply a different design. I suppose you could say that it validates both of them, since they end up with the same answer in the end.<\/p>\n

An obvious strategy for bridging SAML and OpenID is using an OpenID confirmation method. That would be one possible \u00e2\u20ac\u0153simple\u00e2\u20ac\u009d profile, although others are possible, and some have been discussed.<\/p><\/blockquote>\n

I'm not sure I really misunderstand SAML.  I actually do understand that the SubjectConfirmation within SAML offers quite a bit of elasticity.  But SAML does have a bunch of built-in assumptions within the Assertion that make it, well, SAML (Security Assertion Markup Language).  These aren't always the assumptions you want to make.  I'll share one of my own experiences with you.<\/p>\n

CardSpace supports a mode of operation we call “non-auditing”.  In this mode, the identity of the relying party is never conveyed<\/em> to the identity provider.<\/p>\n

The identity provider can still create assertions for the relying party, sign them, and send them back to CardSpace, which can in turn forward them to the relying party.  If done properly, using a reasonable caching scheme, this provides a high degree of privacy, since the identity provider is blind to the usage of its tokens.  For example, one could imagine a school system issuing my daughter a token that says she's under sixteen that she could use to get into protected chat rooms.  In non-auditing mode  the school system would not track which chat rooms she was visiting, and the chat room would only know she is of the correct age.  This is certainly an increasingly important use case.<\/p>\n

My first instinct was to use SAML Assertions as the means for creating this kind of non-audited assertion.  But as Arun Nanda and I started our design we discovered that SAML – even SAML 2.0 – just wouldn't work for us. <\/p>\n

In the specification (latest draft<\/a>), section 2.3.3 says a SAML Assertion MUST have a unique ID<\/strong>.  It must also have an IssueInstant<\/strong>.  When that is the case, the identity provider can always collaborate with the relying party to do a search on the unique ID or IssueInstant, so the desired privacy characteristics dissipate.<\/p>\n

Being a person of some deviousness who just wants to get things done, I said to Arun, “I know you won't like this, but I wonder if we couldn't just create an ID that would be the canonical ‘untraceable identifier’?”  I hesitate to admit this and do so only to show I really was trying to get reuse.<\/p>\n

But within a few seconds, Arun pointed out the following stipulation from section 1.3.4: <\/p>\n

Any party that assigns an identifier MUST ensure that there is negligible probability that that party or any other party will accidentally assign the same identifier to a different data object.<\/p><\/blockquote>\n

I could have argued we weren't reassigning it “accidentally”, I suppose.  But there you are.  I needed a new “Assertion” type – by which I'm referring to the payload hard-wired into SAML. <\/p>\n

It isn't that there is anything wrong with a SAML Assertion.  The “ID” requirement and “IssueInstant” make total sense when your use case is centered primarily around avoiding replay attacks.  But I had a different use case, and needed a different payload, one incompatible with the SAML protocol.  And going forward, I won't be the last to operate outside of the assumptions of any given payload, no matter how clever<\/strong>.<\/p>\n

I have looked deeply at SAML, but am convinced that protocol, payload (call it assertion type or token type, I don't care) and trust fabric need all to be orthogonal.  SAML was a great step forward after PKI because it disentangled trust framework from the Assertion\/Protocol pairing (in PKI they had all been mixed up in a huge ball of string).  But I like WS-Trust because it completes the process, and gets us to what I think is a cleaner architecture.<\/p>\n

In spite of all this, I totally buy Scott's uberpoint that for a number of common use cases SAML and WS-Fed (meaning WS-Trust in http redirection mode) are not more or less functional, but simply a different design. <\/p>\n","protected":false},"excerpt":{"rendered":"

Scott and I agree on a great many things, and I admire his work. But I still believe identity needs a three-dimensional approach in which protocol, payload and trust fabric are completely disentangled.<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[10,8,22],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/686"}],"collection":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=686"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/686\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=686"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=686"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=686"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}