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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: 3 different assertions diagrams


I am quite happy to go for Eve's diagram with the following modifications:

1) Move conditions up to the 'Assertion Molecule' level, for the reasons
given in my other post and because moving it to the upper level allows
support for 'single use' assertions with multiple claims that depend upon a
single verification while attaching the conditions to each claim does not.

Consider the case in which the issuer issues an assertion that contains an
authorization for Alice and a couple of attributes. In a financial services
application it is very likely that the issuer would want to have some
mechanism for tying insurance of the assertion claims as a collection to a
single payment. One of the uses of the Conditions element is to allow that
type of application to be supported in future releases.

The reason for the current positioning appears to be to prevent adding
conditions to a decision element. However a decision element is more likely
to require an Audience restriction not less and the same can be said for the
other types of condition that might be applied such as online verification.

2) It is not clear from the diagram (which is one reason I don't find
diagrams useful) how the syntax is implemented.

I would like the toplevel element to remain <Assertion> regardless of the
type of assertion claim made. This is from experience we had with using OCSP
responses with PKIX applications. Many PKIX supporting applications (PKCS#7,
S/MIME, IPSEC) provide a 'slot' for Certificates and CRLs, there is no such
slot for OCSP tokens and trying to make one was a tedious task which would
not have been necessary had we had the foresight to declare a toplevel
'PKIX' container element which we could then subdivide as necessary in our
own working group.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@east.sun.com]
> Sent: Monday, June 11, 2001 11:20 AM
> To: security-services@lists.oasis-open.org
> Subject: Re: 3 different assertions diagrams
> 
> 
> I have attached a couple of diagrams that I made.  They use a 
> different 
> notation; rather than being true class diagrams, they are "elm tree 
> diagrams" (a notation I use in my DTD methodology) with elements, 
> attributes, and cardinality clearly marked in an XML-ish 
> fashion.  If you 
> think I should publish the legend, let me know; I just ran 
> out of time.
> 
> I'm sorry I didn't get time to try turning the core-0.7 
> proposal into a 
> similar diagram.  If there's interest, I can try to do that 
> later this week.
> 
>          Eve
> 
> At 12:33 AM 6/11/01 -0400, Orchard, David wrote:
> >Eve and I didn't quite manage to synch up stuff this past week.  I'm
> >submitting what I worked on earlier to fulfill my action 
> item and allow us a
> >clearer picture for our assertions discussions.
> >
> >I have attached a word document with 3 different diagrams:
> >1) toppish assertions with recursive structure - 
> assertionPackages can
> >contain other packages
> >2) toppish assertions with non-recursive 3 layer structure
> >3) Assertions 0.7 draft.
> 

Phillip Hallam-Baker (E-mail).vcf



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


Powered by eList eXpress LLC