[OpenID] FW: host-meta and "acct:"

[Will Norris]

On Nov 1, 2009, at 10:48 AM, Peter Williams wrote:

> in the origin al XRI 2.0 draft doc, you see the rules the processor  
> of the
> *original* XRD format must follow (in order to embue the signed blog  
> as a
> being "SAML token" type - for "SAML-assured" name resolution amongst  
> other
> purposes).
>
> Now, from what I can tell, the use of SAML markup for xrd signing had
> nothing to do with SAML as we know it now in its SSO guise: folks just
> borrowed the markup (as was proper) to fashion a method of signing  
> XRDs,
> much as Microsoft applied similar markup in cardspace signaling.
>
> In doing so, folks could also borrow the semantics of the core SAML  
> controls
> that go with SAML type processing. These seems to have been  largely  
> about
> ensuring that the resulting blob acted as a "token" -  once removed  
> from its
> issuing  context. So, you can think of the XRI/XRD servers as an  
> early forms
> of STS: a  signed blob server and signed blob verifier, given the  
> (naming
> and trust) contexts that the TTP-grade name-serving apparatus of  
> ibrokers
> wanted to  manage.

not really... SAML was only included because it had a decent profile  
of XML DSig.  The way it was used in XRI Resolution 2.0 meant that it  
actually violated the SAML spec in several ways.

Signatures in XRD 1.0 are pretty much identical with signatures in XRI  
Resolution 2.0.  The only difference is that they are no longer  
wrapped inside of an embedded SAML assertion.  That was a pretty weird  
way to do it, so we put the <ds:Signature> directly into XRD.  For the  
actual XML DSig profile, we actually copied the text directly from  
SAML 2.0 modulo some additional feedback from SAML editors.


> Hmm. "Token", "once signed", "removed from its context".  Sounds a  
> bit like
> a signed host-meta - an blog XRD sitting on a file server doing what  
> a HTML
> file with a few meta tags for links would also do, except it's a "bit"
> easier to parse (I suppose).

honestly don't see the connection, but okay.


> Now, the host-meta I-D implies that one can sign the elements (having
> included a subject field).

subject is absolutely not required for signing an XRD.  It may be  
required for certain trust models, but seeing as those haven't been  
written yet, nothing can be said about them with any certainty.


> This is what I for my want to know all about - from IETF. How does  
> one sign
> an host-meta profiled XRD, considering the content of the subject in
> particular. For all I know, given the evidence from XRDS-simple,  
> they are
> going to have us do what sort of thing they proposed there, where  
> the URI in
> the subject field will have a fragment on the end, indicating the  
> xml:id
> value.

The subject has nothing directly to do with the actual signing of an  
XRD document.  Depending on your trust profile, the subject URI MAY  
have to match something in the key material used to generate the  
document signature.  If the subject URI has a fragment, that has  
nothing to do with the xml:id value of the <XRD> element.  The only  
connection the <XRD> xml:id has is with the <ds:Reference> in the  
signature.


> We don't know, and we should. Evidently (given the syntax change),  
> it ain't
> gonna happen the way it happened in the era of the XRI-based signed  
> XRD. For
> all we know, folks may even decide that the "xml:id control" (and the
> providerId control similarly) from the "SAML-era" signed XRD are not  
> even
> necessary now.

See above.  The method of generating signatures really hasn't  
changed... you just don't need the SAML wrapper anymore.

-will