OASIS Open

Call will be established by co-chairs through skype.
If participating for the first time, please send skype id to co-chairs by private e-mail.
Note: Due to partial non-accessibility of skype-chat-service:
Please use our alternate chat room at http://webconf.soaphub.org/conf/room/dss-x

1. Welcome by the chair (Juan Carlos Cruellas)

2. Minutes taker
All write into the chat, Stefan assembles and uploads into document area.

3. Roll call

4. Approval of the agenda

5. Approval of minutes from previous calls
 

5.1 Meeting minutes of #168 on 2016-OCT-17

URL=https://www.oasis-open.org/committees/download.php/59153/dssx-168-draft-minutes-shagen-20161017.txt

6. Core and Profile Maintenance

6.1 Local Signature Profile

6.2 Profile for Comprehensive Multi-Signature Verification Reports

6.2.1 Open Action Items from Previous Call(s)

AP on AK to contact Detlev for reminding him to submit modified version of this profile.

6.3 Core

6.3.1 Open Action Items from Previous Call(s)

AP => All members will review the change and errata document provided in Documents/Core and propose any additions that 
      needs consideration.

Input from Andreas (https://www.oasis-open.org/apps/org/workgroup/dss-x/email/archives/201610/msg00016.html):

comments on the Errata document. 

The first two sections are agreed upon, I assume.

Section 3.1.1:

I'm not sure that I get the problem right. The @URIs of the
ds:References correlate to the RefURI of the input documents. Multiple
input documents result in a set of ds:References.

Section 4.1.1:

A bit too tricky for the core I would guess. The request is plausible
but I may introduce complexity I would like to be addressed in a
specific profile, not in the core. Probably it wouldn't be sufficient to
require one element to be present but a set of elements. Or an
alternative set of elements ... and the generic 'MgmtData' will need
special care to be taken! And we would need to define some type of error
response. I would prefer to keep it off the core.

Section 4.2.1:

I don't want to import with this design flaw into the core! It's so PDF
specific, keep it e.g. in the PAdES profile.

Section 4.3.1:

Dtmo the selection of a key of set of keys should be defined by the
usage context of the DSS endpoint. This may be done by the user but in a
user friendly manner. The KeyInfo structure is not fit for this.

A response set will become invalid in an undetermined period of time (
e.g. by key expiry, key renewal). Introducing additional complexities on
the user side.

The enumeration of available keys is critical from the security point of
view.

Moreover the management of the available keys is the primary duty of a
signing server. But this is already weakened by the KeySelector. What
should be filled in here when we don't tell which keys are available? My
proposal would be: drop both, this enumeration request and the KeySelector.

Section 5.1:

Already fixed, I assume.

Section 5.2:

The Verification profile is already dealing with both versions of SAML.
This could be applied to the core, too. ut my recommendation would be:
Uswe SAML 2.0 only!

And additional remarks on Core from Andreas (https://www.oasis-open.org/apps/org/workgroup/dss-x/email/archives/201610/msg00017.html):

I would like to propose some additional changes to the core once we are going to touch it:

1. Each request may be attributed with a set of profiles. Therefore drop the profile attributes from RequestBaseType and ResponseBaseType. Introduce a set of 'AppliedProfile' items to OptionalOutputs.
2. Each request may be attributes with a set of policies. The section regarding 'ServicePolicy' does not explicitly state the option for multiple policies. Introduce a set of 'AppliedPolicy' items to OptionalOutputs.
3. Streamline the core by dropping EscapedXML and InlineXML.
4. Consider replacing dss:AnyType by xades:AnyType. The slightly different structures with same name cause irritations.
5. Clearify the cardinality and the intentions of the optional elements by enumerating them in OptionalInputs and  OptionalOutputs explicitly.
6. Give a the specific type 'xs:boolean' to the flag-type OptionalInputs 'Return*' elements.

7. New Profile Candidates

7.1 PAdES

7.1.1 Open Action Items from Previous Call(s)

7.1.2 Review of Changes in Document / Discussion

7.2 Server Site Profile for JEE Code Signing

7.2.1 Open Action Items from Previous Call(s)

7.2.2 Review of Changes in Document / Discussion

8. AOB

9. Next meetinga 

9.1 Next meeting

Suggested is 2016-NOV-14

Registration Meeting #170:
URL=https://www.oasis-open.org/apps/org/workgroup/dss-x/event.php?event_id=43619

9.2 Further upcoming Meetings

* 2016-NOV-28 (#171)
  URL=https://www.oasis-open.org/apps/org/workgroup/dss-x/event.php?event_id=43620

* 2016-DEC-12 (#172)
  URL=N/A

* Winter-Break

• OASIS Open (General Membership)
• General Public