<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:"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.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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:792600931;
mso-list-template-ids:847144406;}
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 gave up half way through my careful reply, as it was
approaching formatting-incomprehensible …to the poor reader trying follow
it, point by inset counterpoint.<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'>1.is metadata mandatory (XRDS or HTML)? Id claim no, by design
concept. My proffer of proof is an example: the op-initiated unsolicited assertion
(which has no openid-classical user input stage, and thus no discovery, SAML1-like).
The nature of AX update is secondary proffer.<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'>2. Even if metadata via openid discovery is mandatory for an act
of interworking, it’s not “intended” (read “conceived”)
to serve as a control framework (for authorization, privileges, permissions, contract
bindings,…)<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'>3. Some folk evidently see a cousin of the openid2 XRI name servers
(XDI) as the infrastructure in openid’s future that is intended to play
the role (one day) of a fully-fledged, very well-designed authority-based distributed
control framework -representing the large-N OP->SP trust models, the attribute
contracts per SP webapp, the EDI-style “interworking agreement”,
the contract arrangements, the legal terms and conditions… However, XDI is
hardly established practice in OpenID world. I’m not sure if there even exists
a single production usage! It’s obviously R&D. (if anyone can counter
this, let me know; I WANT to try it out, to see if/when it will be viable for
business use.) XDI may not never come to be adopted in the “finalized
specs”, if Nat’s alternative “CX” regime supplants it
(or the highly practical internet-based MPLS-VPNs (per Rapattoni) become the
norm for wire-speed trust networking).<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'><o:p> </o:p></span></p>
<p class=MsoNormal>4. you say ”To my way of thinking, this should be
clarified in OpenID auth 2.1 -- at the least, if an RP is going to use some
non-7.3 mechanism to get an OP Endpoint URL, then that "mechanism"
MUST be populated via traditional Discovery. “<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Why! ..is it so important to you? This proposition essentially
turns OpeniD2 into Shib. I might as well just use Shib, and get the assurance
of properly specified types expressed in a decent type language. OpenId has really
intellectually done nothing if all it does it replace XML with name-value pairs,
and SAML metadata with XRDS, and one metadata-based control model for protocol orchestration…with
another.<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'>But at least you are being direct and honest about the desire.
The “advanced” notions that folks settled on 2 years ago clearly need
revisiting – to see which work, which got adopted in practice, which
should get dumped, and which get another try as they are obviously still
works-in-progress.<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'>5. I suspect, while focusing on points about metadata/authorization/control,
we are really tangentially addressing the bugbear topic of all websso schemes: repurposing,
and the desire of the asserting party to control who can repurpose an
assertion (or reuse a AX response). And of course, that goes to the heart
of the current social debate on who controls a users data, the user or the TTP.
Once user’s own their data, lots of very traditional business models go
out of the door. Lots of governance models also get left behind. Ensuring that such
“old-model” controls can be overlaid on such as websso (to control downstream
actors) has to be expected. So far, the openid project has not been a
foil for shib-like infrastructure governance models (though one can and should overlay
those constructs on OpenID, OPTIONALLY, per trust network)<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'><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'><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> Tuesday, December 30, 2008 7:03 AM<br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> general@openid.net List; specs@openid.net<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 style='margin-bottom:12.0pt'>Peter,<br>
<br>
Wow! These are great questions you're bringing up.<br>
See more replies inline....<o:p></o:p></p>
<div>
<p class=MsoNormal>On Tue, Dec 30, 2008 at 3:25 AM, Peter Williams <<a
href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>The following is rather
academic. Bear with me; I'm making a not so subtle point.</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'>I don't see anything in openid
auth v2 that mandates that the consumer MUST respect the XRDS. That is, if
there exists local means to locate the OP, a consumer may vector the user's
browser there. There is nothing non-conforming in sending the user to an OP
that is missing from the XRDS. Therefore the XRDS is not a control apparatus.
In any case the https cert of the endpoint at which the XRDS is located
may not be valid – given validity is a subjective metric of the RP
– denying validity to the (unsigned) XRDS on the grounds of lack of
assured integrity.</span><o:p></o:p></p>
</div>
</div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>Technically, you are correct
that an XRDS can be ignored, but I think the spec is pretty clear that there
are only 3 "paths through which to do discovery": XRDS via XRI; XRDS
via URL, or HTML Discovery. Given that dictum, it would seem that
if the XRDS is to be ignored, it can only be done so by utilizing HTML based
discovery.<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'>Ok .Why would anyone
believe such a(n academic) claim?</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'>First off, the requirement to
display the form to collect the openid is only noted as a SHOULD. That is, per
any SHOULD conformance constraint, there exist good reasons to do otherwise.
Furthermore, critical failures do not occur merely as a result of following any
such (good) reasons. Only in the case of following the SHOULD counsel will
there exist a </span><span lang=EN style='color:black'>User-Supplied
Identifier. </span><span style='font-size:11.0pt;color:#1F497D'>Otherwise,
there may well exist only "end-user user input".</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class=MsoNormal>Still, the spec clear that whatever the
"user-input" is, it must be normalized into an Identifier, which is
clearly defined in the Terminology sections to be either a URL or an XRI.<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'>While 7.2 procedures are
uniformly expressed in terms of MUST (and they address any and all
"end-user user input") they are contingent of user "input"
(which may not exist). A user may have, by way of contrast to
"input", a existing user session (created by means unknown) and
the consumer MAY (absent denial) initiate openid auth from that state, for example.
This proposition is generally consistent with the notion of
"unsolicited" assertions - which a consumer may legitimately
(and outside of OpenID Auth) "induce".</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>I would argue that if the user "input" doesn't
exist, then OpenID cannot be used -- you can't create an authentication
assertion on a non-existent input. If I'm correct, then the non-existence
of "user input", whatever the form, necessitates the non-use of
OpenID. <br>
<br>
Right?<br>
<br>
Also, an existing "session" implies an existing user-input,
normalized into an Identifier, because I would assert that you can't have an
OpenID Auth "session" without an Identifier.<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'>7.3 appears normative, but
absent a single MUST is not mandatory. That is: openid discovery is optional.</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>Even if discovery is optional, you must agree that *if* any
sort of Discovery is going to be utilized in OpenID-land, then it must abide by
7.3, yes?<br>
Though I would concede that Discovery does appear to be optional -- but only in
the case where the RP already knows the OP Endpoint.<br>
<br>
Here's my logic:<o:p></o:p></p>
<ol start=1 type=1>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'>Discovery is the process of taking an OpenID
Identifier (XRI or URL) and determining various things, most importantly
is the OP Endpoint.<o:p></o:p></li>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'>The only way to determine the OP Endpoint is:<o:p></o:p></li>
</ol>
<ol start=2 type=1>
<ol start=1 type=1>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level2 lfo1'>OpenID Discovery (7.3)<o:p></o:p></li>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level2 lfo1'>Reading an already discovered OpenID endpoint.<o:p></o:p></li>
</ol>
</ol>
<p class=MsoNormal>If the only way to get an OpenID endpoint is via the above
two methods, then *somebody* has to have done Discovery (per 7.3) in order to
populate the mechanism being used in my number 2.2 above.<br>
<br>
To my way of thinking, this should be clarified in OpenID auth 2.1 -- at the
least, if an RP is going to use some non-7.3 mechansim to get an OP Endpoint
URL, then that "mechanism" MUST be populated via traditional
Discovery. <br>
<br>
Otherwise, if Discovery is optional, then that breaks OpenID Auth (IMHO).
The point of OpenID Auth is the user saying, "I control this
identifier", and "I can prove this by setting up Discovery meta-data
that an RP can use to verify the assertion that I control this
URL/XRI". If Discovery is optional, then an RP would never be able
to "trust" the OpenID assertion.<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'>7.3.2 has a clear IF…
which implies that "not if" is a normative possibility. That is:
XRI resolution and YADIS are optional implementation areas.</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, but 7.3.2 is a subsection of 7.3, which defines the
"not if" possibility, which is HTML Based discovery.<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'>7.3.3 has states in which
absence of an HTML discovery document is …an entirely
"legitimate" state. What happens in that state is not defined
(compounded in the case that there has been no use of XRI/YADIS)</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class=MsoNormal>My opinion is that if 7.3.3 has an "absence of HTML
discovery" state, you must still fallback on 7.3, which says there are
only 3 states to pick from. So, if I can only pick 3 states/paths, and I
can't pick HTML-Based Discovery, and I can't pick XRI/XRDS, and I can't pick
URL/Yadis, then there are *no* other valid states to pick from.<br>
<br>
Using that logic, there is no legitimate "fourth state" (that being
one which is not defined). It is defined out of existence by 7.3.<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'>I thus fail to find that
XRDS/HTML is intended to be an authorization/control framework. If it is
supposed to be, its badly specified. I suspect from the phrasing, it supposed
to be convenient metadata.</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>See above. I'm very confident that *if* Discovery is
to be performed, then it must be done via one of the three paths in 7.3. <br>
<br>
I'm less confident about Discovery not being optional since the wording is
unclear, but I think the intent was for Discovery to be non-optional (keep in
mind that mandated Discovery could still allow an RP use a lookup table, or
some other mechanism, so long as the lookup table is initially populated via
7.3 Discovery).<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'> </span><o:p></o:p></p>
<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>
<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'> David Fuelling [mailto:<a href="mailto:sappenin@gmail.com"
target="_blank">sappenin@gmail.com</a>] <o:p></o:p></span></p>
<div>
<p class=MsoNormal><b><span style='font-size:10.0pt'>Sent:</span></b><span
style='font-size:10.0pt'> Monday, December 29, 2008 10:12 AM<br>
<b>To:</b> Peter Williams<o:p></o:p></span></p>
</div>
<p class=MsoNormal><b><span style='font-size:10.0pt'>Cc:</span></b><span
style='font-size:10.0pt'> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a>
List<br>
<b>Subject:</b> Re: [OpenID] DISCUSSION relating to OpenID Discovery 2.1</span><o:p></o:p></p>
</div>
</div>
<div>
<p> <o:p></o:p></p>
<p>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" target="_blank">pwilliams@rapattoni.com</a>>
wrote:<o:p></o:p></p>
<div>
<blockquote style='border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;
border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204)'>
<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>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 windowtext 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;
border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204)'>
<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 style='mso-margin-top-alt:5.0pt;margin-right:0in;margin-bottom:12.0pt;
margin-left:5.25pt'>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.<o:p></o:p></p>
</div>
</div>
<p> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>