[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] ProcessingDetails
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]