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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-core message

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


Subject: RE: Assertion Structure Proposal


Title: 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.

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

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

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.

Best regards.  Tim.

-----Original Message-----
From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
Sent: Friday, March 16, 2001 2:39 PM
To: 'security-core@lists.oasis-open.org'
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.
pbaker@verisign.com
781 245 6996 x227



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


Powered by eList eXpress LLC