[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]