[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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: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
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