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


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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

Subject: Re: [dss] Minutes for 25 Aug meeting

Here's something we were supposed to discuss on list.  Rich's summary is 
good -

At 03:47 PM 9/3/2003 -0400, Rich Salz wrote:

>        Discussion (primarily among Trevor, Pieter, and Nick) about how
>         to query, specify, and manage implicit parameters.  For
>         example, are they all implied by the application profile URI now?
>         The intent of the [*requirements*] document is to require that 
> they almost all
>         be specifiable, with server-determined defaults.  Nick pointed
>         out there are many details that will need to be specified in the
>         protocol document.  Pieter mentioned need for an extensible format
>         for a server to specify the implicit parameters.  Nick suggested
>         not adding a new service endpoint for parameter management.
>         Further discussion moved to email list.

In the schema Juan Carlos left, there was a SignaturePolicyIdentifer:

<xs:complexType name="ProcessingOptionsType">
     <xs:element ref="SignaturePolicyIdentifier" minOccurs="0" />
     <xs:element ref="ServerProfileIdentifier" minOccurs="0" />
     <xs:element ref="IntendedAudience" minOccurs="0" />
     <xs:element name="Other" type="AnyType" minOccurs="0" 
maxOccurs="unbounded" />

I removed this, because I assumed the XAdES attribute of the same name 
would be decided by the server based on the Application Profile, or as an 
Implicit Parameter.  But should we add something like this in to indicate a 
set of Implicit Parameters, above and beyond the Application Profile?

There's not much left in Implicit Parameters, since we've made a lot of 
things explicit.  But here's what the requirements doc says about it:

  - What key and validation info is included (certificate chains, CRLs, etc.)
  - What defaults to use for the other options
  - What other actions the server should perform (e.g. logging or achiving)

I guess it mostly determines the defaults to other things, to the extent 
the Application Profile leaves these unspecified and lets each deployment 
choose its own.

So can we just leave these totally implicit, or do we want a way for the 
client to query these, or specify some set of these through an identifier?


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