OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: Raw notes from F2F Tuesday 28th afternoon


All,

Here are my raw notes from the F2F meeting PM today. I tried to catch the essence of the discussions, so some paraphrasing in here.

Regards,
Erik

Attendees as in the morning.

The minutes from the meeting on the 23rd of July, with the correction from Remon, were approved unanimously:

http://lists.oasis-open.org/archives/xacml/201106/msg00079.html

The “break the glass discussion” ws postponed to Wednesday since David Chadwick wants to prepare some materials for discussion.

Discussion about PIP directive. David Chadwick presented use case: a PDP has connections to 1000 universities which could potentially provide an required attribute. Too inefficient for the PDP to poll all 1000 potential sources.

Has built an “linking service”, in which users can point to where they have accounts. The identity provider can provide a referral to the linking service to the SP, which is represented as an attribute to the PDP. The PDP can then use this referral with the linking service to get additional attributes. David Chadwick would like to standardize this approach.

Jan presented a similar use case. He presented work he has done where a policy can return an obligation on an Indeterminate because of missing XML <Content>, to request for additional information from the PEP.

Hal presented a similar use case as well, which he proposes to be solved with the Attribute Manifest File. AMF allows to define how to look up attributes from PIPs and which other attributes to use as key values for the lookup. Two cases: enhancing the request with attributes and providing attributes by demand of the PDP. Hal presented the AMF draft which he posted a couple of years ago.

AMF files could be produced by scanning of attributes sources or policies.

There was some discussion from Jan, Andy, Erik about that the life cycle of the various pieces of information in the AMF proposal varies.

David Choy: there is a difference in how an attribute authority works for a subject vs a resource attribute.

Hal: there is a trust relationship between the relaying party and the attribute provider.

David Choy: only a human person can know how trustworthy attribute data are.

Hal: AMF spec is not designed to handle quality of attribute data.

David Choy: AMF could be used as a mechanism to tell the system which attributes can be reliably authenticated.

David Chadwick: wants to capture which attributes to trust in XACML.

Erik: if you have a choice between “age” provided by the government  and amazon, why do you connect your PIP to both the government and amazon, and then specify in the XACML policy that you want the government provided age, rather than just connecting the PIP to the government.

David Chadwick: because you are in a broader environment which provides both because there are many users which trust different sources.

Rich: the infrastructure has connections to attribute sources which gets listed in a table with attribute id and issuer. Policy administrator can choose from these and not worry about how to look them up.

David Chadwick: that approach will break down in a federated scenario with multiple authorities.

David Chadwick: different applications need different assurance levels for an attribute. For instance, e-business site can accept a self issued address for a user, while a government authority will require a government vouched address attribute.

Rich: can use multiple attribute ids.

David Chadwick: will lead to explosion of attribute ids.

Erik: why does not the XACML attribute “Issuer” not solve this?

David Chadwick: there can be multiple issuers which are accepted, like any EU government, and do not want to fix a specific one in the policy.

Hal: Let’s have a short break.

** After break:

Rich: There are different layers (figure on whiteboard):

- policy logic

- XACML canonical attributes (attribute id, issuer)

- Runtime objects

- Data sources

- java policy (permission grants)

OpenAz is intended to solve this problem, to transform data from data sources and runtime objects into XACML attributes. AMF format allows to configure OpenAz “mapper”. Enterprise makes XACML attribute definitions with their enterprise environment and its data sources in mind.

David Chadwick: we have started form a different set of assumptions, not enterprise, but a distributed environment with multiple issuers an attribute.

Hal: Did intend to support similar cases, but has optimized for the enterprise environment, with more stable connections, etc. Do not want to add complexity if not needed.

Jan: if you transfer a policy to a different domain, do you also transfer AMF files to the different domain.

Hal: different domain might have entirely different source for the same attributes.

Jan: would change semantics of the rules.

Hal: I am saying the exact opposite, the semantics is the same, although the attributes source is different.

Erik: XACML has a global namespace with the URIs so you should not change the semantics of the identifiers in different environments.

David Chadwick: privileges are granted to attributes, not to users. Attributes are then assigned to users.

Hal to Jan: how do you handle XML <Content>

Jan: application request does not contain some xml content which is needed for XACML decisioning. Source for retrieval of information is more dynamic than in the AMF approach, because the target resource can be different for each application request. AMF and his obligation approach could solve the same problem.

Hal: There is a separation between defining policy and defining how to look up attribute values.

Jan: It’s a restriction that FullFillOn in obligations cannot be “Indeterminate”.

David Choy: configuring attribute lookup requires human interaction to judge trust, so it cannot be automated.

David Chadwick: AMF should be split into two separate issues: the basic connection which is the same for everybody and the trust issue which is separate for each domain.

Erik: We should consider RDF work posted by Paul Tyson on XACML wiki.

Jan: would stay away from the semantic web technologies. Don’t see the connection to the issue.

Hal: does not want to make RDF a requirement for using XACML.

Hal: meeting adjourned




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