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: Domain Model


In reviewing the latest domain model for XACML, I noted the following open
issue related to Security Services 

"Should all the assertions relationships be 1:* to the authorities to
represent that a given assertion can only be produced by 1 given authority,
or left as *:* to represent that a given assertion can be produced by many
authorities."

To be precise a "given assertion", meaning the very same particular
assertion that was created at a particular time by a particular thing in a
particular location, i.e. an instance of an assertion, could by definition
only be produced by a single authority. However, an assertion with the same
semantic content could be produced by multiple authorities.

Relevant to both SSTC and XACML the following definition may need a tweak:

Authorization Policy	An authorization policy is a statement about the
terms and conditions under which a given resource can be accessed in a
particular way. For example: members of the group "Sonic Death Monkey" are
granted "use" privileges on the resource "/usr/bin/guitar." I suggest the
use of the term "manipulated" or "handled" in place of "accessed" for the
definition of an Authorization Policy. I am beginning to think that access
control is a subset of authorization; hence, the definition as given would
be a good definition of Access Control Policy. (Good thing they both start
with "A" in case we ever have to change the meaning of XACML! But I'll leave
that alone for now since we just finished our charter revision process;-)

Dave Parrott, any chance you could perhaps do a textual pass on how DRM
layers into the static model? At a minimum, I think we established on the
last conference call that DRM includes the policy enforcement point, which
is out of scope for SAML and XACML.

More to come ...

P.S. Gil, thanks for producing this stuff!!!!!

 

Simon Y. Blackwell 
CTO 
Psoom, Inc. 
Voice & Fax: 415-762-9787 



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


Powered by eList eXpress LLC