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: Final text of ballot


> {AP-1} Generalized or specialized solution 
>
> [...]
>
> Question: which of these statements do you agree with (only one, please)?
> Answer:
> 1. We should develop a generalized solution as an interim step to satisfying
> the specific requirements identified by the Use Cases sub-committee.
> 
> 2. We should directly address the requirements identified by the Use Case
> sub-committee.

I vote for "1".

Rationale: I don't think this group's work needs to be completely hamstrung
waiting for the Use Case & Reqs group, but, that said, it should be prepared to
nomalize its work with the UC&R group's eventual output. 



> {AP-2} Questions the PEP can ask the PDP
>
> [...]
>
> Question: What type of information should the PEP expect to receive from the
> PDP?  The answers are not mutually exclusive, so answer "yes" to as many ways
> as you want.
> 
> Answer:
> 1.      "Yes/No/Can't decide".
> 2.      All information in the assertions supplied by the PEP.
> 3.      Specific attributes requested by the PEP.
> 4.      Any information that the PDP can discover.


I vote for "3"  and "4". 

Rationale: I secon d Charles' rationale on this one. 



> {AP-3}  Question: should we define a PDP-PDP protocol?
> Answer:
> 1.      Yes.
> 2.      No.


I vote for "1". 

Rationale: short answer -- see section 2 of RFC 2903 "Generic AAA Architecture".
Folks who've been down this path a bit before us think that it's a resonable
part of a general picture. (However, I'll agree it might not be a part of a very
narrowly defined picture). 



> {AP-4}  The number of assertions in a message
>
> [...]
> 
> Question: How many assertions may appear in a single message?
> Answer:
> 1.      Only one.
> 2.      Only one related pair.
> 3.      An unlimited number.


I vote for "3", sorta. 

Rationale: I'm presuming that we wouldn't just take Authn & Authz assertions and
stick 'em in the "application data" portion of a TCP segment and ship it to the
other party without some attendant information such as the sort of questiono
we're asking, the the target resource, and so on.

I tend to believe the protocol at hand, whether it is  PDP-PEP or PDP-PDP or
both, will define some number of "operations" and "operands" to go with them
(e.g. "please examine these assertions in the context of this proposed operation
on this resource and return a yes/no decision" or "please examine these
assertions, plus these asserted attribute names, and tell me some stuff"), and
therefore it is perhaps possible to package-up multiple protocol
operations+operands into a single protocol "message" (aka "PDU") and send that
off to the other party. In fact, an apparently very similar notion is a "MUST"
in "AAA Authorization Requirements", RFC 2906, Section 2.1.3.



> {AP-5} Combining components
> Question: Should the core assertions/protocols group explicitly identify in
> its model that components may be combined (e.g. the Authority may be combined
> with the PDP)?
> 
> Answer:
> 1.      The model should explicitly identify that components of the model may
> be combined.
> 2.      The model should not explicitly identify that components of the model
> may be combined.

I vote for "2".

Rationale: I voting this way in the context that on which hosts one runs one's
service components in a deployment are largely site-specific and present
technology typically makes it transparently possible. 


> {AP-6} Assertion validation component
> Question: Should the core assertions/protocols group identify "assertion
> validation" as a separate component in its model?
> 
> Answer:
> 1.      The model should identify "assertion validation" as a separate
> component.
> 2.      The model should not identify "assertion validation" as a separate
> component.
> 

I vote for "2". 

Rationale: I think that "assertion validation" is something that a PDP, for
example, has to do in carrying out its duties. In that context, asking another
entity "hey, is this here assertion valid?", is a sort of narrow use of a
PDP-PDP/PEP-PDP protocol.  So given my vote on {AP-3}, I don't think we
necessarily need to explicitly call this out. 



JeffH


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


Powered by eList eXpress LLC