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


My comments in italics.

{AP-1} Generalized or specialized solution
My Vote:
1. We should develop a generalized solution as an interim step to satisfying the specific requirements identified by the Use Cases
sub-committee.

I think we should develop a general solution (within reason) that satisfies the current Use Cases and has some hope of
satisfying future as yet unforeseen use cases. I don't know if I would term a general solution an "interim step".

{AP-2} Questions the PEP can ask the PDP
My Vote:
3.      Specific attributes requested by the PEP.
4.      Any information that the PDP can discover.

I would like to vote for both of these choices this way: a PEP can request either specific or all attributes. In our
product (and others as well), the ability to return additional information to the PEP is extremely valuable. Sometimes the
PEP might know want it needs, and in other cases it doesn't.

A PDP should be free to provide only those attributes that it considers the PEP is allowed to see.

{AP-3}  Question: should we define a PDP-PDP protocol?
My Vote:
Abstain.

I don't know enough about what a PDP-PDP protocol might entail. How much of it might overlap the proposed XACML? How much of it might be satisfied by a general PEP-PDP protocol? How much would be unique? Perhaps this should be an area of future work for the TC.

{AP-4}  The number of assertions in a message
My Vote:
3.      An unlimited number.

I like the S2ML feature where multiple entitlements can be stuffed into one message. This should cut down on the number
of interactions between PEPs and PDPs.

{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)?
My Vote:
2.      The model should not explicitly identify that components of the model may be combined.

I don't see why the model would need to do this, other than maybe allowing us to specify how to combine pieces of
messages that would have been sent between merged components. Other than that, it seems to me that combining
components is an implementation issue.

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

I'm not sure I understand what being a separate component means in this context. Does it imply that the protocol includes
request-response messages for assertion validation? I think that might be a good idea, to allow out-board assertion
validation assertion in the manner of OSCP.

begin:vcard 
n:Knouse;Charles
tel;fax:408-861-6811
tel;work:408-861-6890
x-mozilla-html:TRUE
url:www.oblix.com
org:Oblix;Engineering
adr:;;18922 Forge Drive;Cupertino;CA;95014;USA
version:2.1
email;internet:cknouse@oblix.com
title:Principal Software Engineer
fn:Charles Knouse
end:vcard


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


Powered by eList eXpress LLC