[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Groups - dss-requirements-1.0-draft-03.pdf - Process a n dDeadline information?
>> How to Identify Requestor >> ---------------------------------------------- >> I think 3.2.1 bullets 2 and 3, about what types of signed >> attributes are >> used to identify the requestor, should be changed to: >> - RFC 3280 GeneralName (for a CMS signature) >> - SAML Assertion (for an XML-DSIG signature) >It seems to me that SAML assertions work and are easily included in our >spec. Thus, I think we should certainly support their use. It's not clear >to me that we necessarily need to support any other method until/unless we >receive a concrete proposal of something else to use or find a specific >deficiency. I guess I don't agree, so here is a proposal for a UsernameToken, thus we don't have to have the baggage of SAML <xsd:complexType name="UsernameTokenType"> <xsd:annotation> <xsd:documentation>This type represents a username token per Section 4.1</xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="Username" type="wsse:AttributedString"/> <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute ref="wsu:Id"/> <xsd:anyAttribute namespace="##other" processContents="lax"/> </xsd:complexType> Anthony Nadalin | work 512.436.9568 | cell 512.289.4122 |---------+-------------------------------> | | Robert Zuccherato | | | <robert.zuccherato@e| | | ntrust.com> | | | | | | 04/25/2003 02:40 PM | |---------+-------------------------------> >----------------------------------------------------------------------------------------------------------------------------------------------| | | | To: "'Trevor Perrin'" <trevp@trevp.net>, Gray Steve <steve.gray@upu.int>, dss@lists.oasis-open.org | | cc: | | Subject: RE: [dss] Groups - dss-requirements-1.0-draft-03.pdf - Process a n d Deadline information? | >----------------------------------------------------------------------------------------------------------------------------------------------| Trevor; > I'm not sure when we want to get this done. The sooner the better, I > guess. Do people think it's realistic to get a candidate > final version > that we can discuss on May 5, the next meeting? I think that is a realistic goal. I would like to see a candidate final version in time for the next telecon, if at all possible. > Securing the Transform Chain > ---------------------------------------------- ...snip.... > So this is a complicated issue. I think the one requirement > we should add, > is that if the client sends transformed input to the server > when requesting > a signature (per 3.3.2), then the client should have the > ability to send > dsig:References for external transform data, which the server > can choose to > incorporate in a manifest (per Gregor's initial suggestion) > or a "secure > cache" (per Joseph's suggestion) or do something else (such as ignore > them). So I'd append this sentence to 3.3.2, if people agree: > > "The client may send a list of dsig:References for URIs that > contribute to > the transform sequence, so that the server may incorporate > these into the > signature in some fashion". > > and say that the details of how the server does this are out of scope. That seems reasonable to me. > Signing Human-Readable data and XML > ---------------------------------------------- > For this, I agree with Ed Simon that "you could sign both the > raw data and > the transformed result, AND have your protocol define the > exact requirement > in relating the two". This wouldn't have any impact on our > protocol, the > client could just request the signature of two > dsig:References that happen > to be related in this way, under some Signature Policy (per > 3.4.4) that > specifies this relation. > > The other proposed approach is to sign the transforms that > produce the > human-readable data. I don't think this would affect the > protocol either, > the client could again request the signature of two > dsig:References, one > referring to the raw document, one to some transforms. > > So I don't believe we need to make any changes to the > requirements doc to > accomodate this. I agree. > How to Identify Requestor > ---------------------------------------------- > I think 3.2.1 bullets 2 and 3, about what types of signed > attributes are > used to identify the requestor, should be changed to: > - RFC 3280 GeneralName (for a CMS signature) > - SAML Assertion (for an XML-DSIG signature) It seems to me that SAML assertions work and are easily included in our spec. Thus, I think we should certainly support their use. It's not clear to me that we necessarily need to support any other method until/unless we receive a concrete proposal of something else to use or find a specific deficiency. > Linked Timestamps > ---------------------------------------------- > Unsure where we are on this. My feeling is that unless we > could spec these > out completely, so that any relying party can figure out how > to parse and > verify timestamps produced by any TSA, including the > supporting protocols > used to retrieve data from trusted archives and the 2-phase > protocols to > produce these and so on, than there's no point to just doing this > half-way. And spec'ing this out fully would be very > complicated. And then > there's IPR issues.. > > So I think we should just make sure that we can extend our > time stamps to > support linking schemes in the future, but not grapple with > their details: > http://lists.oasis-open.org/archives/dss/200304/msg00011.html I think that your proposal on this subject is entirely reasonable, however we should definitely discuss this topic again at the next telecon. Thanks, Robert.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]