<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText62865 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>One thing we have to remember, in these days of OpenID2, is the option/obligation to use RP Discovery. (JISC folk in the UK programming OpenID1 solutions at this point are really just wasting their research funds, in my view.)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>As the OpenID Auth 2 spec says, "realm" is an 'rp identifier'. In this capacity as an identifier [for a set of endpoints], its a critically important input to rp discovery. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>When a "federating-class" openid OP, like Yahoo!, performs RP discovery, it gets to optionally apply the trusted resolution option of the XRI/OpenID spec [set]. There, the authority revolver can optionally enable 1 or more SAML2-based TTPs to issue statements - ultimately talking about the RP [endpoint set]. The algorithm does this of course by distributing one or more SAML assertions in the XRDS result's seq of XRDs. By parsing, interpreting and applying the authority and delegation semantics in those assertions (see XRI2 resolution proposed std), the OP obtains a standard means to enforce its (IDP-centered) federation policies, per classical hub-spoke trust models. Presumably some OPs will also BE the TTPs that issue the SAML assertions, as well as the party providing distributed revolver services</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>If we look to XRIs/HXRIs now in realm signals, just as URLs can be wildcarded so can one have wildcarded XRIs (as the XRI spec makes abundantly clear, when discussing its method for handling versioning). If the realm is thus signaled to the OP as a wildcarded XRI, we will have to carefully inspect the authority resolution component of the XRI2 resolution algorithm to see what one does with each SAML assertion statement, as these statement then interplay with the XRI wildcard resolution. Presumably SAML profiles will be created, leveraging the authorization statements of the SAML2 standard.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Now, to this peon, this stuff is obviously all pretty well thought out and highly extensible (and obviously as applicable to phone/jabber endpoints as to classical web endpoints). But I cannot really find any worked examples of the whole system coming together, on openid.net. </FONT><FONT face=Arial size=2>What little we do see being disclosed is discussed in 9.2.1 of the OPenID Auth 2.0 spec. There we see disclosure of the notion of "verification" of return_to, and specification of a concrete method (albeit in summary form). </FONT><FONT face=Arial size=2>One compares the return_to with the results of discovery on the rp identifier (realm). For the purposes of THIS discovery-control (vs other law#4-centric controls) involving "realm", we see the rule for replacing wildcards with "www". (What happens when the realm is an XRI or HXRI, that has multiple wildcards!??) Also, we see a special case, where with metadata may indicate the RP is operating in directed identity model, such that the RP's endpoint(s) becomes the realm value. but, we must also note that an OP is obligated to test for the realm meet certain conditions in this special case (basically, absence of wildcards). </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Presumably a conformance tester (not that we are allowed third-party conformance testing in this community) would check that an OP behaves correctly on this topic (i.e. never releases a positive assertion to a non-conforming/non-correct endpoint). One is acting correctly if one releases negative assertions, presumably. This is a little worry of course, as signaling design for error responses is a traditional vulnerability area in insecure/immature handshakes.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV></DIV>
<DIV id=idSignature43106>
<DIV><FONT face=Arial color=#000000 size=2><SPAN style="FONT-SIZE: 7.5pt">_________________________<BR></SPAN><B>Peter Williams<BR></B><SPAN style="FONT-SIZE: 7.5pt">Chief Information Security Officer<BR>Mobile (805) 416-6305</SPAN></FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Nate Klingenstein<BR><B>Sent:</B> Thu 4/24/2008 7:12 PM<BR><B>To:</B> Peter Williams<BR><B>Cc:</B> Trey Long; general@openid.net<BR><B>Subject:</B> Re: [OpenID] Multiple Domains and State<BR></FONT><BR></DIV>
<DIV><PRE style="WORD-WRAP: break-word">Peter,
You're right. I'd naturally assumed it to be part of the response(as
a wildcarded return_to), because there's no real meat to putting it
only in the request, which is never signed in the first place.
However, the return_to must be the return_to in the request, e.g. not
wildcarded.
Okay, now I'm baffled.
Nate.
On 25 Apr 2008, at 01:56, Peter Williams wrote:
> - realm provides scope to a request, explicitely. No mention is
> made of scoped responses.
</PRE></DIV></BODY></HTML>