On Tue, Dec 30, 2008 at 7:00 PM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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.</span></p></div></div></blockquote><div><br>Yes, I encountered the same thing in my responses. :) <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"><a href="http://1.is" target="_blank">1.is</a> 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.</span></p></div></div></blockquote><div>Correct me if I'm wrong, but in your proffer case, an unsolicited assertion will still have an OpenID Identifier, correct? Before accepting such an assertion, the RP should verify that the OP sending the assertion is the entity who can actually make that assertion. To do that, the RP must either perform 7.3 "discovery" on the claimed identifier (just for validation purposes), or the RP must validate the Claimed Identifier in some other way (referencing my previous thread, I would argue this "some other way" must always have its root in 7.3 Discovery -- though it's really just verfication in this scenario).<br>
<br>So, the question becomes: How does an RP figure out who can (and who cannot) make an assertion on behalf of a given Claimed Identifier? <br><br>Are you saying that the manner in which this is done is merely "SUGGESTED" by the spec, but that RP's can pretty much choose to figure this out any old way they want? See my response to your #5 below for why this is such a big deal to me.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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,…)</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p></div></div></blockquote><div>I'm not sure you can separate the two -- If "metadata via OpenId Discovery" is mandatory, then it becomes an authority over the Claimed Identifier (regardless of intent).<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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).</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p>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. "</p>
<p> </p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p></div></div></blockquote><div>Yes, it's very important -- see my response to your #5.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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)</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p></div></div></blockquote><div>Here's why this is so important to me:<br><ol><li><b>User Centric Identity<br> </b>Ideally, I want the user to be in control of their identity, including which OP asserts for them, and also including what an RP can do with a user's identity. Mandatory 7.3 Discovery provides a framework to enforce these types of things (see my <a href="http://wiki.openid.net/OpenID-Discovery#IIInbspIssues/IdeasforDiscussion">other proposals</a> here relating to discovery). If 7.3 Discovery is not mandatory, then RP's can ignore the XRDS stuff (theoretically) and do whatever they want (i.e., ignore the wishes of a user).<br>
<br></li><li><b>RP Confusion</b><br>If RP's are not required to do 7.3 discovery (at some point), then where does authority come from? One might say, "there is no authority", but then the notion of an assertion becomes very dilluted -- <a href="http://gmail.com">gmail.com</a> might make an assertion on my <a href="http://sappenin.com">sappenin.com</a> OpenID Identifier, and how will an RP know to accept or deny that assertion? Unless I'm missing something, making 7.3 Discovery optional seems to remove the main foundation on which OpenID stands, thus confining OpenID to a world of pre-defined assertion relationships (i.e., google and yahoo meet in an offline room, agree to accept assertions from each other only) -- there's nothing "Open" about that. It should be renamed "contractual id", and we already have a world-wide deployed framework for this type of one-to-one credentials arrangement -- it's called a username/password.<br>
<br></li><li><b>End-User Confusion<br></b>With 7.3 Discovery being optional, how should users define their OP? They can't rely on 7.3 mechanisms with any degree of certainty, since there's no requirement to respect their 7.3 metadata (in this hypothetical world).<br>
<br></li></ol>Ignoring for a moment you assertion that "<span style="font-size: 11pt; color: rgb(31, 73, 125);">This proposition essentially
turns OpeniD2 into Shib", </span>I'll reverse the question somewhat and pose it back to you: What's wrong with OpenID mandating an authority scheme (i.e., a way to specify that a particular OP is authoritative for a particular Claimed Identifier) via 7.3 Discovery?<br>
</div></div><br>