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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

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


Subject: Issues identified in the core and some profiles


Dear all,

While going again through the core and some profiles I have hit some issues, for which I would ask some kind of resolution. I might identify more issues in the forecoming days as I am reviewing certain aspects of the core and some profiles. By the way, I have been looking to the Issues section of our Kavi....but not find out how to create a new issue....Stefan, could you let me know how to do it? Once I know it I will create these issues in the Kavi and so record them

Regards

Juan Carlos.

LIST OF ISSUES

A. DSS core 1.0

1. ClaimedIdentity.

In DSS core 1.0 the type saml:NameIdentifierType is used; this is a type defined in SAML 1.0. SAML 2.0 has substituted this type with NameIDType. I propose that version 2.0 of the core uses this type.

2. RequestTransformedDocument.

DSS Core 1.0.
This element does not seem to work in the case that the request contains more than one XML (XAdES) signatures. It only contains one attribute for identifying the number of a ds:Reference. And the text only speaks about "the" XML signature. If the text is changed to make it clear that the integer i value in the attribute corresponds to that ds:Reference that occupies the ith position once the request has been serialized, then this could work.

3. VerifyManifests.

DSS Core 1.0.
In the XML schema parts within the core document, there is not such element present.
In the XML schema file, this element does not appear either!!!.

4. Constraints.

There should be some mechanism for passing constraints to the server. Should this appear into the core?


B. Multi-signature verification report.

1. ReturnVerificationReport

The profile defines three different levels of details...could there be more?


C. ASYNCHRONOUS PROCESSING PROFILE

1. PendingRequest

This profile allows OptionalInputs?. Text says: " Any additional inputs to the request. This element may be used e.g. for authentication data"

I am not sure that in any of the optional inputs in the core there is an OptionalInput? for conveying authentication data.
Apart from that, I would not expect that in the pendingRequest would appear any optional input that repeats some of the optional inputs present in the initial request that repeats things like the server policy, the signature policy, the validation data, etc because, what if the information in this pendingRequest is different from the information in the initial request?




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