<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText99530 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Looking for what SAML2 and OpenID2 each do best, and where they act in common with regard to security handling rules for their respective "Authentication Request protocols", I noted the following in [1]</FONT></DIV><FONT face=Arial color=#000000 size=2><FONT face=ArialMT size=2><FONT face=ArialMT size=2>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P align=left>"Note that if the </FONT></FONT><FONT face=CourierNewPSMT size=2><FONT face=CourierNewPSMT size=2><AuthnRequest> </FONT></FONT><FONT face=ArialMT size=2><FONT face=ArialMT size=2>is not authenticated and/or integrity protected, the information in it MUST NOT be trusted except as advisory. Whether the request is signed or not, the identity provider MUST ensure that any </FONT></FONT><FONT face=CourierNewPSMT size=2><FONT face=CourierNewPSMT size=2><AssertionConsumerServiceURL> </FONT></FONT><FONT face=ArialMT size=2><FONT face=ArialMT size=2>or </FONT></FONT><FONT face=CourierNewPSMT size=2><FONT face=CourierNewPSMT size=2><AssertionConsumerServiceIndex> </FONT></FONT><FONT face=ArialMT size=2><FONT face=ArialMT size=2>elements in the request are verified as belonging to the service provider to whom the response will be sent. Failure to do so can result in a man-in-the-middle attack."</FONT></FONT></P></BLOCKQUOTE>
<P dir=ltr align=left><FONT face=ArialMT size=2><FONT face=ArialMT size=2>First, saml and OpenID are similar in that both characterize the fundamental controls in their handshake design in terms of "requests" (not responses).</FONT></FONT></P>
<P dir=ltr align=left>Second, in the SAML case, metadata may be signed or not signed; and, requests be signed or not signed, similarly. As we see above, "verification" is obligatatory for the unsigned-request/unsigned-metadata cases. If I replace the term verification with the term "OP/RP discovery", we have a situation much like in OpenID2, mapping identifiers/realms into endpoints.</P>
<P dir=ltr align=left>I'm wondering which infrastructure to use to distribute my SAML metadata (and possibly a Realtor's public FOAF data). One option is to put it in our application repository (RETS - an RDF like SPARQL server, that has a GETmetadata URI-bound transaction and that permits "community-extensions" to the (RETS) metadata schema). Another option is to put it in the XRDS/XRD, so XRI resolution can be shared when securing flows between SAML2 endpoints and also between OpenID endpoints. (I could even extend the RETS transaction model privately, to deliver XRDS documents!) Now, if I go with XRI as the data model, would I define an extension for the XRD schema, importing the SAML2 metadata schema say? If I do that, can this legitimately be done by private entities in the management model, or is this right reserved for an OASIS process?</P><FONT size=2><FONT size=2>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P align=left>The elements in the XRD schema are intended for generic resource description, including the metadata necessary for XRI resolution. [2]</P>
<P align=left>An XRDS document is intended to serve exclusively as an XML container document for XML schemas from other XML namespaces. Therefore it has only a single root element </FONT><FONT face="Courier New,Courier New" size=2><FONT face="Courier New,Courier New" size=2>xrds:XRDS </FONT></FONT><FONT size=2>in its own XML namespace identified by the XRI </FONT><FONT face="Courier New,Courier New" size=2><FONT face="Courier New,Courier New" size=2>xri://$xrds</FONT></FONT><FONT size=2>. [2]</FONT></P>
<P align=left><FONT size=2>It also has a single attribute, </FONT><FONT face="Courier New,Courier New" size=2><FONT face="Courier New,Courier New" size=2>xrds:XRDS/@xrds:ref </FONT></FONT><FONT size=2>of type </FONT><FONT face="Courier New,Courier New" size=2><FONT face="Courier New,Courier New" size=2>anyURI </FONT></FONT><FONT size=2>that identifies the resource described by the XRDS document. The formal XML schema definition of an XRDS document is provided in Appendix A. [2]</FONT></P></BLOCKQUOTE>
<P dir=ltr align=left></FONT><FONT face=ArialMT size=2><FONT face=ArialMT size=2>[1] <A href="http://www.oasis-open.org/committees/download.php/22389/sstc-saml-profiles-errata-2.0-wd-05-diff.pdf" target=_blank>http://www.oasis-open.org/committees/download.php/22389/sstc-saml-profiles-errata-2.0-wd-05-diff.pdf</A></FONT></FONT></P>
<P dir=ltr align=left><FONT face=ArialMT size=2><FONT face=ArialMT size=2>[2] <A href="http://www.oasis-open.org/committees/download.php/17293" target=_blank>http://www.oasis-open.org/committees/download.php/17293</A></P></FONT></FONT></FONT></DIV>
<DIV id=idSignature13228 dir=ltr>
<DIV><FONT face=Arial color=#000000 size=2><SPAN style="FONT-SIZE: 7.5pt">_________________________<BR></SPAN><B>Peter Williams<BR></B></FONT></DIV></DIV></BODY></HTML>