<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: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.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
p.Default, li.Default, div.Default
{mso-style-name:Default;
margin:0in;
margin-bottom:.0001pt;
text-autospace:none;
font-size:12.0pt;
font-family:"Arial","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:1430470067;
mso-list-template-ids:2099777088;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</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>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I suspect the following is 3-5 years out from reality ….
but it is fascinating:-<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 style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>http://www.oasis-open.org/committees/download.php/29748/xdi-rdf-model-v11.pdf<o:p></o:p></span></p>
<p class=Default style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:
3.0pt;margin-left:.5in'><b><i><span style='font-size:14.0pt'>Link Contracts </span></i></b><span
style='font-size:14.0pt'><o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.5pt'>One
of the core design goals of XDI is that controls over XDI data
sharing—everything from authorization and access control to data usage
and termination—be expressable as XDI documents so they can be fully
described in the XDI graph.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.5pt'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.5pt'>W3C culture makes RDF and
FOAF (and IRI). <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.5pt'>OASIS culture takes the research
models and makes engineered XDI and XRI.<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 style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<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"'> David Fuelling
[mailto:sappenin@gmail.com] <br>
<b>Sent:</b> Monday, December 29, 2008 10:12 AM<br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> general@openid.net List<br>
<b>Subject:</b> Re: [OpenID] DISCUSSION relating to OpenID Discovery 2.1<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Peter,<br>
<br>
Thanks for your input...see my replies inline. <br>
<br>
david<br>
<br>
On Mon, Dec 29, 2008 at 4:36 PM, Peter Williams <<a
href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>> wrote:<o:p></o:p></p>
<div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>The main problem I have is
…you are changing the character of XRDS (and XRI 2.0 resolution).</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class=MsoNormal>Yes, but I'd be open to accomplishing these ideas without
doing so.<o:p></o:p></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> In 1, you are turning
metadata discovery into a authorization/control framework. Won't be long before
you will want a "#include QXRI" line in the XRDS, that imports XRDs
from a superior policy authority, and require the XRI client resolver to now to
"augment" the XRDs with those from the control authority. If OpenID
needs an policy-based authorization framework, let's consider that in its own
right (and there is LOTS AND LOTS of previous work to draw on). Let's not break
the (nicely working) metadata model, tho.</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class=MsoNormal>Well, it already is an authorization/control
framework. The value of the OP endpoint in your XRDS document is what
controls what your OP is. Proposal #1 merely extends this to say that you
need 2 OP's instead of one, and possibly only for certain sites.<br>
<o:p></o:p></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>In 2, why doesn't XRI already
do exactly what you want? Surely, the intelligence you want is in the query
syntax, and that is precisely what XRI resolution gives you? The notion that
one discovery agent would proxy to n other discovery agents based on criteria
from the resolution request seems important (and, again, what other sso
discovery protocols already do).</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class=MsoNormal>Most likely I'm just too ignorant of XRI to actually know
how it works in full. Can you provide an example of how I could do #2
with existing mechanism? <br>
<br>
In my #2 "spec" (it's not nearly fleshed out enough to be called such
a thing) I have three methods to do OP Delegation. "Service"
delegation already is possible with current XRI mechansims, I agree (I note
that scenario just to clarify how I think OpenID Discovery should work with
regard to OP's). But it is less apparent to me how to do method's two and
three of my "spec" (i.e., pick an OP based on the RP's domain, or
based upon some feature of the OpenID transaction).<br>
<o:p></o:p></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'>In 3, what is wrong with the
XRI extension model? It seems to do exactly what you want.</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class=MsoNormal>Hmmm...this is a possibility, but my thinking was that these
discovery extensions would be OpenID specific. In other words, the notion
of overriding the definition of XRDS/XRD "priority" attribute is
pretty specific to OpenID discovery, and specific to the "2-headed
auth" example in particular. I'm not opposed to making these ideas
into a more generic XRI extension, but I'm not sure they're really that
generic. Plus, it would be nice to have something that is "OpenID
Endorsed" (or condemned) in order to ensure it makes it into OpenID best
practices (e.g., always do this....or NEVER do this).<br>
<o:p></o:p></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>Now I can see an argument that
just as folk could not typically adopt/implement the X.500 DAP query model, but
could adopt simpler queries expressed in simplified ldap urls, so we
might need to make a simplified XRI resolver based on lxri:// urls…
building on the momentum that wants to simply parse an XRDS stored in a static
file (rather than a full-power XRDS stream generated as a result of
resolving an XRI query seeking metadata from the i-broker network)</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class=MsoNormal>Yes. <o:p></o:p></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>If 2 and 3 above were expressed
in terms of: here is the lightweight profile of XRI tuned to those 3 purposes,
and its carefully tuned to be easy to program…that might fly as a work
item. Its taking the current design and simply making it easier to adopt,
focusing on</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span> <span
style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<div style='border:none;border-left:solid windowtext 1.5pt;padding:0in 0in 0in 4.0pt;
border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color blue'>
<div>
<div style='border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0in 0in 0in;
border-color:-moz-use-text-color -moz-use-text-color'>
<p><b><span style='font-size:10.0pt'>From:</span></b><span style='font-size:
10.0pt'> <a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>
[mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>]
<b>On Behalf Of </b>David Fuelling<br>
<b>Sent:</b> Monday, December 29, 2008 6:25 AM<br>
<b>To:</b> <a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a>;
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a> List<br>
<b>Subject:</b> [OpenID] DISCUSSION relating to OpenID Discovery 2.1</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p> <o:p></o:p></p>
<p style='margin-bottom:12.0pt'>Not sure if this made it through to everyone
due to the mail list malfunction, so resending just in case.<br>
<br>
david<o:p></o:p></p>
<div>
<p style='margin-bottom:12.0pt'>---------- Forwarded message ----------<br>
From: <b>David Fuelling</b> <<a href="mailto:sappenin@gmail.com"
target="_blank">sappenin@gmail.com</a>><br>
Date: Fri, Dec 26, 2008 at 6:58 PM<br>
Subject: DISCUSSION relating to OpenID Discovery 2.1<br>
To: "<a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a>"
<<a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a>>,
"<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>
List" <<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><br>
<br>
<br>
All,<br>
<br>
I'd like to propose that the following ideas be considered as discussion points
in the OpenID 2.1 Discovery WG. I've updated the <a
href="http://wiki.openid.net/Working_Groups%3AOpenID_Discovery" target="_blank">OpenID
2.1 Discovery WG wiki page</a> to reflect these ideas, and have provided two
very rough-draft proposals (currently formulated as extensions) to juice up the
dialog. The ideas are summarized below -- I'd be curious to hear any and
all feedback.<br>
<br>
Thanks!<br>
<br>
David<o:p></o:p></p>
<ol start=1 type=1>
<li class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;
mso-list:l0 level1 lfo1'><b><i>Enabling two (or more) headed
OP authentication</i></b><br>
The idea here is to allow an end-user to specify two (or more) OP's in the
<Service> portion of their XRD so that an RP MUST receive auth
assertions from both OP's before granting access to protected
resources. See a rough-draft idea proposal here: <a
href="http://wiki.openid.net/OP-MultiAuth" target="_blank">OP MultiAuth</a>.
XRI Resolution 2.0 seems to currently prohibit this by default per section
4.3.3: "<i>If two or more instances of the same element type
have identical priority attribute values (including the null value), the
consuming application SHOULD select one of the instances at random. This
consuming application SHOULD NOT simply choose the first instance that
appears in XML document order.</i>" Thus, in order to indicate
to the RP that both OP URI's should be used at the same time, an
aditional <Type> element is used to signify that identical priority
URI's should be used together for the purposes of OpenID Auth.<o:p></o:p></li>
<li class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;
mso-list:l0 level1 lfo1'><b><i>OP Delegation based upon various
characteristics of an OpenID transaction</i></b><br>
The idea here is to allow an end-user to delegate authority over a
particular OpenID Identifier to divergent OpenID Providers (OP's),
depending on certain characteristics of a Relying Party and/or certain
characteristics of an OpenID transaction. For example, an Identifier
might specify a different authoritative OP depending on the OpenID-related
Service being employed (e.g., OpenID 2.0, OAuth, or others); the RP Domain
(*.<a href="http://example.com" target="_blank">example.com</a>); or a
pre-defined service Class (e.g., one OP for single-factor auth, and
another OP when two-factor Auth is required). By providing
OpenID Identifiers with the ability to specify multiple OP's based on
particular characteristics of each OpenID transaction, end-users will be
able to utilize the best OP for any particular OpenID transaction as they
see fit (i.e., more control in the hands of the user). See a rough-draft
here: <a href="http://wiki.openid.net/OP-Delegation" target="_blank">OP
Delegation</a>.<o:p></o:p></li>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'><b><i>Discovery Extensions</i></b><br>
The OpenID Discovery specification should define ways for discovery
to be extended by other services. For example, the
OAuth+OpenID specification may want to peform discovery in slighly
different ways than regular OpenID Auth 2.1 does. Likewise,
ideas numbers 1 and 2 above could be implemented as extensions to
Discovery instead of being included in the main 2.1 Discovery
specification.<o:p></o:p></li>
</ol>
</div>
<p> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>