Topics from Monday's DSS-X call

[Andreas Kuehne <kuehne@trustable.de>]

Hi all,


here are some topics from the last call that I would like to comment upon:

'Optional' elements:

    My proposal for the hierarchy of 'Optional' looks like this:


    type OptionalInputs (base schema)

        - ServicePolicy
        - Language
        - Other

    type OptionalInputsBase (core schema), derived from OptionalInputs

        - ClaimedIdentity
        - Schemas
        - AddTimestamp

       
    type OptionalInputsSignType (core schema), derived from OptionalInputsBase

        - SignatureType
        - IntendedAudience
        - KeySelector
        ...
        - SignatureAlgorithm
        - SignatureActivationData
       

    type OptionalInputsSignType (in implementation schema), derived from core's OptionalInputsSignType

        extending the OptionalInputsSignType with profile specific types


    I would assume that this approach does support the majority of use cases well.

    
Replacement for xs:any (used as holder of arbitrary content):

    The best way to replace the anys is still somehow unclear to me because I'm not quite sure why the structure of the 'AnyType' was chosen for DSS 1.0 in this particular way. The use cases I can think of could have been handled by a single element of type 'xs:anyType'. But the 'original' sequence of anys leaves me a bit lost, as the xs:any itself is able to contain a set of elements.
    But looking at the elements currently defined as dss:AnyType the intention seems to be to hold just one instance of something. So I would second the proposal to replace the existing set of dss:AnyType with the dsb:Base64DataType. In the rare cases where a multiplicity may be useful (ClaimedIdentity.Supporting holding a SAML token and a JWT) it should be considered on the level the surrounding element (in the mentioned case allow multiple supporting infos).

Refurbishing of included schemes:
    The most invasive change required to support multiple transport syntaxes is to modify included/imported schemes. I did outline the reasons for it in section 2.6 of the core 2.0 draft (https://www.oasis-open.org/committees/document.php?document_id=62270&wg_abbrev=dss-x) and explained the effects on a sample structure in 2.6.4 .

    I do consider it as a bad approach, but don't know any better. Comments and remarks welcome.


Greetings,

Andreas

-- 
Andreas Kühne 
phone: +49 177 293 24 97 
mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas Kühne

Company UK Company No: 5218868 Registered in England and Wales