Securely Available Credentials (SACRED) - Credential Server Framework
draft-ietf-sacred-framework-07

protocol-bss-08 describes a "create account" operation that is not discussed in any significant detail in the framework (though RFC3157 requirement S13 substantiates this need). I think the framework document could use a little text that describes the overall process of creating an account at a SACRED server. What sort of association does a user need to have with a server for this sort of self-enrollment to work (what is the applicable trust model of self-enrollment)? What are the risks of uploading credentials to a server with which you have no association (e.g. are there risks of initial man-in-the-middle attacks when self-enrollment takes place)? How do clients anticipate the structure of identifiers (usernames/credential namespaces under which they attempt to enroll) at SACRED servers with which they have no association?

draft-ietf-sacred-protocol-bss-08.txt could be greatly enhanced by adding
an introduction.  The section that is labeled "introduction" doesn't
seem to contain an introduction to either the document or the protocol.

Also, why doesn't this document contain an informative reference to the
framework document?  I read them in the wrong order, and it was much
easier to understand draft-ietf-sacred-protocol-08.txt after I read
draft-ietf-sacred-framework-06.txt.

Comments on draft-ietf-sacred-framework-06:

  In section 5.2.2, plaease make three changes:
    - Change "x.509" to "X.509"
    - Change "trusted SACRED roots" to "SACRED trust anchors"
    - Change "roots from other applications" to "trust anchors from other applications"

  Please change the title of section 5.2.4 to "Denial of Service."

Comments on draft-ietf-sacred-protocol-bss-08:

  Throughout the document, please change "privacy" to "confidentiality."

  In section 1, please change "(confidentiality, authentication, etc.)" to "(integrity, authentication, and confidentiality)."