← Prev in month ← Prev in thread
Next in thread → Next in month →

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

From
Mishra, Prateek <>
Date
2003-01-23T22:15:35+00:00
ID
Thread
[security-services] additional responses to comments ondraft-sstc-meta-data-00.doc
Comments on meta-data-00 draft.

1.

http://lists.oasis-open.org/archives/security-services/200211/msg00019.html

Response: incorporated editorial 
changes.

[quote]

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. 

[end-quote]

 

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.

 

2. 

http://lists.oasis-open.org/archives/security-services/200212/msg00018.html

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>
← Prev in month ← Prev in thread
Next in thread → Next in month →