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: Request for clarification


Ahh .. therein lies the flaw in my Exchange rule "except if the message
is sent directly to me" (so it didn't get filed into OASIS and didn't
get processed until you pointed out it).  Thank you Phillip for your 
response and my respect for the clarity of the answer. Of course, many
good answers raises new questions as well ...

1) Is there supposed to be an Element <Evidence> in section 1.4.4.2 of 
   draft-sstc-core-10?  Is there a later draft where this is removed
   in favor for Phillip's <Advice>?  That would certainly avoid the 
   messy "what is evidence" questions raised by the draft-sstc-core-10 
   Element <Evidence> raises (simply due to the denotation of its
identifier)


2) I "drag in XTASS" because the saml:advice definition is word-for-word
identical with the XTASS:evidence even to the extent of the repeating
the typographical error!  Doesn't this rather suggest similarity too?
If it is evidence something must attest to its veracity and enable its
interrogation, and indeed a trust framework seems like an appropriate 
(but perhaps non-exclusive) means.

2) What we have in saml:Evidence is not actually "evidence" at all, but
rather substantiating information that may (or may not) be useful to
the PDP.  I suggest inclusion of Philip's language with a clarification: 
>> >> The purpose of evidence is the following: I need to decide
>> >> whether user Alice should have access to resource R; it turns
>> >> out user Alice has several assertions E that she can reasonably
>> >> claim to belong to her. I can now submit the evidence E
>> >> to the PDP together with the questions "Can Alice access R?".
>> >> The AzDecision assertion returned by the PDP must carry
>> >> all of the assertions submitted as evidence, as these condition
>> >> its judgement.    
Add:  "The AzDecision assertion does not assert the veracity of
       the submitted assertions, and acceptance of an AzDecision
       assertion does not require acceptance of the enclosed 
       supports (i.e., the submitted assertions)."

3) On the other issues, my questions (2a) and (2b) are mutually exclusive.
Without consistency requirements there cannot be a "jointly and severally"
clause on the 'pseudo-evidence' element. (Yes, I realize the draft document
doesn't use have such a clause there, but perhaps it was an omission;
Philip's 
response suggests there MUST not be a "jointly and severally" clause of
the 'pseudo-evidence'.

>> >>   b) What, if any, are the consistency requirements between multiple
>> >>      saml:evidence elements within an AuthorizationDecisionAssertion?
>>
>> NONE.

4) Yes, I definitely agree with the following, although it suggests
   use of a Uniform Resource Name (URN) because "identical" should be
   time-invariant. 
>> >> 4) What properties describe the saml:evidence available in a 
>> >>    SAMLResponse to a SAML protocol AuthorizationQuery, and how 
>> >>    does this depend on the evidence provided in the query? 
>>
>> Evidence in response MUST be identical to evidence in query.



(yeah, the typo REALLY IS THERE!)
   My XTASS draft is version 0.9: January 5th 2001 reading as follows:
   and omits the closing parenthesis after the word "assertions."  The
   identical wording and typo occur in the core-discussion-00.  This is
   (to many) "evidence" of similarity :-).  

XTASS VERSION 0.9 JAN 05 2001
3.1.6 Evidence
The Evidence element permits evidence supporting the assertion claims to be
cited,
either directly (through incorporating the claims) or indirectly (by
reference to the
supporting assertions. Currently no evidence elements are defined.

DRAFT-STSC-CORE-9.doc (same wording, different numbers, as CORE-10)
1.5.1 Element <Advice> 438
The <Advice> element permits evidence supporting the assertion claims to be
cited, 439
either directly (through incorporating the claims) or indirectly (by
reference to the 440
supporting assertions. 441

-----Original Message-----
From: Mishra, Prateek [mailto:pmishra@netegrity.com]
Sent: Friday, July 27, 2001 10:54 AM
To: Lerner, Michah, ALSVC
Cc: OASIS Security Services TC
Subject: RE: Request for clarification


I believe Philip has already responded to your note,
but here are my opinions as well.


>>1) Is saml:evidence different from saml:advice? Already 
>>xtass:evidence 
>>   shares identical wording with saml:advice, including the missing \)

I have no idea why you are dragging XTASS in here. SAML evidence and
advice are completely different notions. Advice carries entirely
optional and open-ended data as part of an assertion; evidence is
defined as a sequence of assertions contained with two elements:

	AuthorizationQuery
     AzDecisionAssertion.


>>2) Since an AuthorizationDecisionAssertion is "made subject to the 
>>   assertions in the Evidence element"
>>   a) Does the AuthorizationDecisionAssertion certify the textually
>>      enclosed saml:evidence as valid "jointly and severally", as 
>>      defined by the Element <Claims>?  If so, what is the purpose 
>>      of carrying the evidence, and is the evidence unique or 
>>complete?

The purpose of evidence is the following: I need to decide
whether user Alice should have access to resource R; it turns
out user Alice has several assertions E that she can reasonably
claim to belong to her. I can now submit the evidence E
to the PDP together with the questions "Can Alice access R?".
The AzDecision assertion returned by the PDP must carry
all of the assertions submitted as evidence, as these condition
its judgement.


>>   b) What, if any, are the consistency requirements between multiple
>>      saml:evidence elements within an AuthorizationDecisionAssertion?

NONE.

>>3) Is saml:evidence local to the saml:AuthenticationDecisionAssertion 
>>   that textually encloses it?  

Yes.

>>4) What properties describe the saml:evidence available in a 
>>SAMLResponse
>>   to a SAML protocol AuthorizationQuery, and how does this 
>>depend on the
>>   evidence provided in the query? 


Evidence in response MUST be identical to evidence in query.

>>//Michah
>>
>>
>>
>>>>


- prateek


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


Powered by eList eXpress LLC