OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [security-services] additional responses to comments ondraft-sstc-meta-data-00.doc

Comments on meta-data-00 draft.



Response: incorporated editorial changes.


In Section 2.2, I suggest that we add an optional element called PassThrough (the element name is not important per se’).

This element would specify the name of an HTTP parameter.

Its purpose would be to name the parameter whose value the source site guarantees to preserve and pass to the destination site upon redirection.

This would be specified as optional for both POST and Artifact profiles.



Response: I believe this discussion is now subsumed by the proposed expansion of the web browser profile that Scott Cantor is driving. We can revisit

this issue once Scott has put together the new flows.




A) There should be a way to collect multiple SourceSiteDescriptors into one document that would define a set of source sites

Response: I have added a "container" element for multiple Source AND Destination Sites.

B) A SourceSiteDescriptor should have an identifier (an arbitrary string) that indicates which source site the descriptor describes

Response: I have added an <SourceID> and <DestinationID> element appropriately to each of the descriptor elements. They each contain

informational strings.

C) It's good that the TrustModel element covers all of the HTTP authentication methods, not just client side certificate.

For the BasicAuth trust model, site administrators might be reluctant to provide their passwords in the clear, especially if source site descriptions are public documents.

I suggest including an option to publish the SHA-1 digest of the password. Of course this requires SAML implementations to compute the digest of received passwords.

Response: Maybe the simplest thing to do is ONLY to support passage of hashed passwords? I really dont see a problem with that and will add to the next draft.

D) Restrict KeyInfo to X509Certificate.

Response: As the only planned use for this element is to carry X509.V3 certificates, it seems reasonable to use <dsig: X509Certificate>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC