<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>We do the same thing in US realty, essentially. Using a metadata
standard (that has various forms, including csv and xml schema, and could
easily dynamically spit out the RP’s own XRDS too) each RP subscribes out-of-band
to the attribute authority. It’s like what SAML would do if its metadata
for attribute contracts was more complete (and used). In our metadata, the data
model is RDF like – with types and classes. Security Contracts are just oneobject
to be searched for, like more typical data on members and listings.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>We now have several spokes that upon receiving the SAML post (or
would-be openid assertion) then go and pull the membership attribute
relating to the primary key from the attribute authority. We have 1000 spokes
who do the equivalent of the SAML/OpenID using a variety of proprietary handoff
techniques, mostly developed over the last 15 years of doing this sort of thing
on the web. Some of the techniques are relics of the pre-web versions of the
same flow, using authorized dialbacks!<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Of course this is just the classical SAML push then pull model.
What we did a bit better was allow the RP metadata to be actually published in a
repository with a common access method, so it ACTUALLY auto-configures the RP
software (once the policy is set, and expressed). Change policy, software
adjusts.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The attribute authority is itself often a chaining and
aggregation proxy, much like the X.500 directories chaining model. Now that RDF
is getting mainstream and works in the core of SQL-server 2008, I can see us making
our authorities perform dynamic collation of subordinate attribute authorities,
quite soon, at high data rates.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>All we really need for openid is some XRDS extensions that
describe the attribute contracts.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces@openid.net [mailto:general-bounces@openid.net] <b>On Behalf Of </b>Nate
Klingenstein<br>
<b>Sent:</b> Thursday, November 13, 2008 7:53 AM<br>
<b>To:</b> Ben Laurie<br>
<b>Cc:</b> OpenID General<br>
<b>Subject:</b> [LIKELY_SPAM]Re: [OpenID] OpenID SREG best practice question<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Ben,<o:p></o:p></p>
<div>
<div>
<div>
<p class=MsoNormal><br>
<br>
<o:p></o:p></p>
<p style='margin:0in;margin-bottom:.0001pt'><span class=apple-style-span>Clearly
as (if?) more attributes get added into the mix more thought</span><o:p></o:p></p>
<p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:9.0pt;
font-family:"Helvetica","sans-serif"'>will have to go into this aspect.</span><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>We share and utilize a very large number of attributes, and
many applications do need much more information than email address. Some
need less. In our deployments, each service has the ability to express
which attributes it needs. See, for example, this page, and click on
"Show requested attributes":<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal><a
href="http://www.switch.ch/de/aai/participants/allresources.html?show=all">http://www.switch.ch/de/aai/participants/allresources.html?show=all</a><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Then, the IdP administrator can choose to alter these
defaults for their local userbase. This has worked out great for these
apps, but it's not a general solution (and doesn't help in your situation
regardless).<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>User-managed release of attributes was a key design tenet
for us that has seen very little uptake in the real world. We've tried
interfaces that allowed users to individually select which attributes, building
from a default set, they would like to block or enable the release of.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>1) It created a surge in help desk calls as
well-meaning users locked themselves out of apps.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>2) Most users didn't care at all, and the ones who did
care, didn't care on such fine granularity.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>We're now toying with interfaces that are opt-in/opt-out,
and ones that can give "levels of service" based on how much
information you're willing to reveal, e.g. persistent pseudonym = personalized
content. It gives the user the ability to do consent-based release for
many services, and for services that are absolutely necessary to providing an
education for the student, they won't be prompted. We'll see if these are
more successful.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Something certainly has to be done, though. We don't
want the IdP administrator to be a gatekeeper for all services. It works
very well for the major apps with our large user bases, but it's not scaling
down to the small collaborations. I suspect this is why Eric is so keen
to have some formal research into the problem.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Take care,<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>Nate.<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>