Re: [dss] ProcessingDetails

[Juan Carlos Cruellas Ibarz <cruellas@ac.upc.es>]

Trevor 

See below...

At 14:58 12/01/2004 -0800, Trevor Perrin wrote:
>
>Hi Juan Carlos,
>
>Here's our old discussion on this:
>http://lists.oasis-open.org/archives/dss/200312/msg00007.html
>
>The gist is you wanted more detail to say exactly what failed and why, 
>whereas the current structure just lets you say:
>
><ProcessingDetails>
>         <ValidDetail>IssuerTrust</ValidDetail>
>         <ValidDetail>ValidityInterval</ValidDetail>
>         <IndeterminateDetail>RevocationStatus</IndeterminateDetail>
>         <InvalidDetail>Signature</InvalidDetail>
></ProcessingDetails>
>
>However, what I liked about the current structure, was that it provides 
>useful high-level info, such as:
>     <IndeterminateDetail>RevocationStatus</IndeterminateDetail>
>
>without telling you precisely that a CRL or OCSP retrieval failed, which 
>might be harder to convey than it's worth.
>
>But maybe we could take the current structure and add the ability to attach 
>more specific information to any of the details, such as a URI <Code> that 
>profiles can define, or a text <Message>, and an xs:any so profiles can add 
>whatever else they want:
>
What I see of this approach is that:

a. The URI <Code> gives more specific information similar to the tag
of the elements that can be choiced from StatusReasonType (CRLNotReached,
etc).
Under this assumption I would agree on having this indication in the way
you propose.
b. The Message you propose could give the oportunity of generating
human-readable
messages as you show in your example.
c. The xs:any would provide means	 for including more specific details: for
the case of 
CRLNotReached, for instance, one could add an identifier of the CRL that
was not
reached, so that the functionality contemplated in the structure of the
message I sent you
would be satisfied, once these structures had been incorporated.

In summary, I think that by adding these URI <code>, <Message> and xs:any
containers the
functionality could be cover.

This brings me to another point: would it be worth to work on defining the
structures that could expand
the details information  up to the level I mentioned in my email (ie,
giving identification of the CRLs not
accessed, etc), not for incoporating them into the core, but in the context
of a new profile whose only
purpose could be define this type of inforamtion? The outcome of this work
could then be incorporated
by other profiles in their corresponding validation responses....


Juan Carlos.
>
><ProcessingDetails>
>         <ValidDetail Type="IssuerTrust"/>
>         <ValidDetail Type="ValidityInterval"/>
>         <IndeterminateDetail Type="RevocationStatus">
>
<Code>urn:someprofile:indeterminate-detail:CRLNotReached</Code>
>         </IndeterminateDetail>
>         <InvalidDetail Type="Signature">
>
<Code>urn:oasis:names:tc:dss:1.0:invalid-detail:ReferenceFailure</Code>
>                 <Message>The ds:Reference's hash doesn't match the 
>document</Message>
>         </InvalidDetail>
></ProcessingDetails>
>
>
>Your thoughts?
>
>
>Trevor 
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php.
>