RE: Assertion Structure Proposal

>Phill - Why don't you walk us through this during the next core/protocols
>telecon?  Many of the elements need further explanation before one could 
>really comment.

Sounds good.

>Does this structure allow for links to other assertions that are required 
>in order to fully rely on this assertion (the S2ML DependsOn element)?

Sounds to me like this is a <Condition>


>Is the "AssertionRequest" structure a proposed substitution for the 
>existing Protocols section?  If so, should there not be a corresponding 
>"Response" structure?

I guess so, it was more trying to elucidate stuff than 'replace'. Do 
we need a response structure to wrap round the assertion or is the 
assertion enough???


>I suggest you explain more fully in the telecon. 
>As an additional agenda item, why don't we have the discussion about 
>whether it is preferable to have many simple messages or few more 
>complicated ones.  I don't believe we have formally decided that issue.

Lets see if we can get to some concrete choices here. 'Simple' and 
'complex' are subjective terms...

My preference would be for a few simple messages if that is possible.

		Phill


Best regards.  Tim. 
-----Original Message----- 
From: Philip Hallam-Baker [mailto:] 
Sent: Friday, March 16, 2001 2:39 PM 
To: '' 
Subject: Assertion Structure Proposal 



<Assertion> 
   <!-- Basic tagging info --> 
   <AssertionID> 
   <RequestID>? 
   <Issuer> 
   <IssueDate> 
   <ValidityInterval> 
   <!-- The Assertion --> 
   <Claim> 
      <Authority> 
         <Subject>+ 
            <Account> <Role>? 
            <URI> | <ds:KeyInfo> | <Ticket> | <Bearer> | ANY 
         <Object>+ 
            <URI> | <ds:KeyInfo> | ANY 
      
   <!-- Optional XTASS Control Elements --> 
   <Conditions>          <!-- Discard any assertion carrying this element 
                              It is essentially a criticality flag --> 
   <ReIssue>             <!-- Omit --> 
   <Evidence>            <!-- Omit --> 


The element <Bearer> is used to indicate that the party presenting the 
assertion has been authenticated as the subject. 
ANY indicates a private extension schema in its own name space. 


We also need a query syntax, something like 


<AssertionRequest> 
   <!-- Basic tagging info --> 
   <RequestID> 
   <Requestor>? 
   <IssueDate>? 
   <ValidityInterval>? 
   <!-- The Assertion --> 
   <Query> 
      <Authority> 
         <Subject>+ 
            <Account> <Role>? 
            <URI> | <ds:KeyInfo> | <Ticket>  | ANY 
         <Object>+ 
            <URI> | <ds:KeyInfo> | ANY 
   <Respond> 


Phillip Hallam-Baker 
Principal Scientist 
VeriSign Inc. 
 
781 245 6996 x227