<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>Peter,</div><div><br class="webkit-block-placeholder"></div><div>I'm not sure how it's germane to this discussion, but there are at least two distinct issues with proxies and gateways. These issues are particular to spoofing and reassertion, which are the easiest ways to implement a gateway, and consequently the ways that are really widespread.</div><div><br class="webkit-block-placeholder"></div><div>The impact on the privacy of the end user you describe is one concern. They consume and parse user information before passing it along.</div><div><br class="webkit-block-placeholder"></div><div>However, security is also impacted: without the elaborate proxying and delegation design you note, they eliminate the end-to-end trust between providers and often incidentally destroy information. We prefer to make our authorization decisions by attribute, and the issuer/authority for those attributes can be important for their interpretation. This information is usually lost in proxying models, and is actually remarkably difficult to preserve.</div><div><br></div><div>Large content providers are facing this problem now as the pool of deployers grows. Multiple organizations that have no resources to run their own IdP are banding together to form single IdP's. This gateway makes differentiation of users for resource allocation and contractual fulfillment challenging, while access control rules must be more complicated. I'd like to see such single IdP's in the future at least provide attributes to allow for differentiation, and would like to see IdP outsourcing services arise for organizations that would prefer to use them.</div><div><br class="webkit-block-placeholder"></div><div>That all said, there are often situations where these perceived shortcomings of proxying are actually desirable. A set of applications may wish to appear to many IdP's as a single application for simplicity, or backend applications may not want to understand federated identity. A gateway is perfect for these use cases.</div><div><br class="webkit-block-placeholder"></div><div>Just another tool in the identity kit,</div><div>Nate.</div><div><br class="webkit-block-placeholder"></div><div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div dir="ltr">If I generalize the topic now, I did note in browsing some Shibboleth design session notes on an Internet2 wiki that Scott Cantor has previously expressed reservations on gatewaying - on the grounds (and here I interpret a little) that they interfere with privacy features. The point being, I think, that the very notion of gatewaying sp-initiated flows back to back (and yet further back-to-back WITHOUT formalized proxy control signaling) interferes with the writer-to-reader (end-to-end) assumptions that the security services built into the websso protocols usually make, in their privacy-enhanced signaling. While cardspace clearly has the capability to enforce writer-to-reader (relying on TPM to TPM and crypto control system to enforce an ORCON policy), its making broad assumptions about trust hardware and trust OS deployment that is of course not "yet viable," in today's web.</div><div dir="ltr"> </div></span></blockquote></div><br></body></html>