[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