{"id":777,"date":"2007-05-10T09:54:35","date_gmt":"2007-05-10T17:54:35","guid":{"rendered":"\/?p=777"},"modified":"2007-05-10T10:07:45","modified_gmt":"2007-05-10T18:07:45","slug":"pamela-dingle-on-multiple-issuers","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=777","title":{"rendered":"Pamela Dingle on multiple issuers"},"content":{"rendered":"<p>Some <a href=\"http:\/\/eternaloptimist.wordpress.com\/2007\/05\/10\/i-got-the-issuer-blues\/\">clear&nbsp;and advanced thinking <\/a>from Pamela Dingle at <a href=\"http:\/\/eternaloptimist.wordpress.com\/\">Eternal Optimist<\/a>:<\/p>\n<p style=\"margin-left: 30px\">Here is a simple and likely RP scenario that I\u00e2\u20ac\u2122d like you to consider:<\/p>\n<p style=\"margin-left: 60px\">A given site wants to allow users to pay with either their Visa or their Mastercard information card. They do not, however, accept American Express. How should they create their security policy such that Visa and Mastercard managed cards are both highlighted in the Identity Selector if present, but also such that an American Express Card is grayed out and not clickable?<\/p>\n<p style=\"margin-left: 30px\">Would you all agree that this is a pretty important thing for a Relying Party to be able to implement? I think it\u00e2\u20ac\u2122s important too, but I don\u00e2\u20ac\u2122t see an easy way to actually accomplish it.<\/p>\n<p style=\"margin-left: 30px\">To my knowledge, there are two ways to choose what cards are highlighted and what cards are grayed out in the identity selector:<\/p>\n<ul>\n<li>\n<p style=\"margin-left: 30px\">if a card\u00e2\u20ac\u2122s issuer matches the <em>value<\/em> of the issuer parameter<\/p>\n<\/li>\n<li>\n<p style=\"margin-left: 30px\">if the entire set of required claim <em>types<\/em> are all present in a given card.<\/p>\n<\/li>\n<\/ul>\n<p style=\"margin-left: 30px\">In the scenario above, the issuer parameter is a non-starter, because Windows CardSpace v1.0<em> only accepts a single issuer<\/em>. And at this point in the identity metasystem, what WCS says, goes. I can specify Visa\u00e2\u20ac\u2122s STS, or I can specify Mastercard\u00e2\u20ac\u2122s STS, or I can choose not to specify an STS at all, but I cannot specify exactly two of them. Bottom line: as soon as I need to create a policy that lists more than one issuer, but less than all issuers, I cannot use the issuer statement.<\/p>\n<p style=\"margin-left: 30px\">So &#8211; that leaves us claims. Claims are great &#8211; when you can use what\u00e2\u20ac\u2122s in them. In this case, however, the RP can\u00e2\u20ac\u2122t work with claim values, only with claim types. In order to succeed in my scenario using claims, I would need to be able to specify a claim type that both Visa and Mastercard offer, but that AmEx doesn\u00e2\u20ac\u2122t, in order to have the right cards show up and the wrong cards gray out. What exact claim type would that be? The only way I can see to architect such a thing is to have a commonly agreed upon but different claim<em> <\/em>type for every possible distinct combination of credit cards. Let\u00e2\u20ac\u2122s say that there are 6 major credit card companies out there. How many permutations &amp; combinations of claim types would be necessary to cover every single combination of 2,3,4, and 5 accepted cards, and how ugly would it be to add a new credit card?<\/p>\n<p style=\"margin-left: 30px\">It could theoretically be done. Identity Providers would have to start publishing two very separate types of claim types \u00e2\u20ac\u201d contentless claim types that advertise capabilities, and content-rich claim types that would deliver actual data values. If you implement the capability claim types as constants and not as directory schema, it isn\u00e2\u20ac\u2122t so bad \u00e2\u20ac\u201d but the big problem is, it takes the \u00e2\u20ac\u02dcdistributed\u00e2\u20ac\u2122 out of this wonderful distributed system.<\/p>\n<p style=\"margin-left: 30px\">Unless things change (or unless I\u00e2\u20ac\u2122m proven wrong, maybe I\u00e2\u20ac\u2122m just missing some answers and need to be educated), here is what I fear will happen: users would go to a Relying Party Site, only to be presented with an HTML \u00e2\u20ac\u0153menu\u00e2\u20ac\u009d of supported managed card providers. They would then click on the card provider logo, and an HTML object would be invoked which has an issuer tailored to that single provider. Is this what we want to have happen?<\/p>\n<p style=\"margin-left: 30px\">If it does happen, I can see all sorts of fallout:<\/p>\n<ul>\n<li>\n<p style=\"margin-left: 30px\">Common claim types are no longer needed to ensure the user picks the right card. This is good.<\/p>\n<\/li>\n<li>\n<p style=\"margin-left: 30px\">Every RP has to alter HTML to support a new Identity Provider. This is bad, or at least worse than adding a url to an allow or deny list.<\/p>\n<\/li>\n<li>\n<p style=\"margin-left: 30px\">The ability for a Relying Party to require the same claims from every Identity Provider becomes damaged. This is bad. Of course, with issuer in the state it is in, I would say that no matter what, this is already the case.<\/p>\n<\/li>\n<li>\n<p style=\"margin-left: 30px\">The system is more distributed, but MUCH less consistent for the user. This is bad.<\/p>\n<\/li>\n<li>\n<p style=\"margin-left: 30px\">It opens the door for the more established Identity Providers to set arbitrary rules on what attributes \u00e2\u20ac\u0153must\u00e2\u20ac\u009d be asked for in order to interoperate, forcing Relying Parties to embed different code for each provider. This is bad.<\/p>\n<\/li>\n<\/ul>\n<p style=\"margin-left: 30px\">Of course, all of this hinges on how important the initial card presentation ceremony becomes to the world. Remember that we are not talking about the RP\u00e2\u20ac\u2122s ability to accept or reject a card once it has been selected. We are only talking about how to get the most user-friendly initial display of highlighted or grayed out cards when the selector opens. Maybe this small part of the information card ceremony won\u00e2\u20ac\u2122t end up being that important \u00e2\u20ac\u201d but I predict that it will. If I could have have any kind of solution to the problem, it would be the ability not just to list multiple issuers, but to apply Boolean logic to the list, so that I could represent ideas like \u00e2\u20ac\u0153every issuer except these two\u00e2\u20ac\u009d.<\/p>\n<p style=\"margin-left: 30px\"><a target=\"_blank\" href=\"https:\/\/www.identityblog.com\/\" title=\"Identity Blog\"><font color=\"#52759a\">Kim<\/font><\/a>, <a target=\"_blank\" href=\"http:\/\/self-issued.info\/\" title=\"Self Issued\"><font color=\"#52759a\">Mike<\/font><\/a>, what can we do? Is this as big a problem as I\u00e2\u20ac\u2122ve made it out to be, or am I just whining about something inconsequential? What is your vision of how my scenario could be implemented? Can this be solved with a few best practices, or do we need to change the way that information card RP security policies can be specified?<\/p>\n<p>Pam&#39;s thinking is unassailable.&nbsp; The problems she outlines are issues we just didn&#39;t have time to solve in version 1.0 of CardSpace.&nbsp;<\/p>\n<p>We were aware of them,&nbsp;but wanted to get the first round of our technology &#8220;out there&#8221; so everyone could start doing proofs of concept and implementations that would help clarify the right approaches.&nbsp; I think in practice we&#39;ll have time to fix this before people&nbsp;anyone really&nbsp;&#8220;feels&#8221; it.&nbsp; Not all credit card providers will be supporting information cards at once.&nbsp;&nbsp;Meanwhile we&#39;ll be pumping out more&nbsp;advanced versions of CardSpace that address the issue.&nbsp;&nbsp;<\/p>\n<p>The same problems&nbsp;Pam describes with respect to issuers apply with respect to RP support for multiple token types (e.g. SAML tokens plus OpenID tokens).&nbsp; Currently we can address this&nbsp;by accepting&nbsp;&#8220;any&#8221; token type, and that will get us by for a while, but ultimately we will need to be able to specify rich combinations.<\/p>\n<p>WS-SecurityPolicy is powerful enough to express boolean logic, so theoretically the relying party can publish metadata that&nbsp;has all the capabilities Pam calls for.&nbsp; For example, you can say&nbsp;you will accept American Express AND Visa as issuers but not Diner&#39;s Club.&nbsp; You can&nbsp;also require different claim types from different issuers.&nbsp;&nbsp;So the architecture&nbsp;is adequate&nbsp;to the problems.&nbsp;&nbsp;<\/p>\n<p>So given that the architecture is right, it represents&nbsp;an opportunity for our competitors&#8230;&nbsp; And we ourselves are&nbsp;working really hard to solve this problem in our next version &#8211; before it anyone feels the pain.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>WS-SecurityPolicy is powerful enough to express boolean logic, so theoretically the relying party can publish metadata that has all the capabilities Pam calls for.  <\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[7,5,4],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/777"}],"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=777"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/777\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=777"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=777"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=777"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}