Thanks Jim, 1. I agree about switching from <WS-Token> to <RoleToken>.
2. I agree with OctetString to accommodate compressed XML (e.g. EXI). 3. Re combining algorithms, my opinion is that we should use the full XACML combining algorithm identifiers and, of course, clients would provide friendly names/interfaces (e.g. "AND" instead of "urn:oasis:xacml:...:deny-overrides"). Re which combining algorithms are supported, could PLASMA * for at least v1, define a limited set (just "AND" and "OR"); or * require all mandatory XACML-specified combining algorithms. 4. Re specifying policy options, maybe borrowing the XACML <Target> element would be sensible; would not PLASMA policy options basically equivalent to AND'ing a GetCMSToken <PolicySet>/<Policy>/<Target> with the server's <PolicySet>/<Policy>/<Target>? (Not that the server's policy engine has to be XACML, but even in other policy languages, the "AND'ing of targets" concept would still apply.) Ed ________________________________________ From: [email protected] [[email protected]] on behalf of Jim Schaad [[email protected]] Sent: Thursday, December 06, 2012 15:53 To: [email protected] Subject: [plasma] Plasma Document Updates I am currently in the middle of doing a large revision of the two documents that I am the primary author on. In the process of doing this update, I have a few issues that I would like people to comment on. 1. I am considering changing the element "WS-Token" in "AuthenticationType". Since the only place where this is currently being used is for dealing with role tokens, I believe it would be useful to change the name of the element to "RoleToken" as this would make it clearer what goes here. 2. In the CMS document I have change the label from being an ASN.1 encoded string to being the XML encoded string. However, I am wondering if we should make this an OCTET STRING which holds the XML encoded string so that we can allow for compression to occur as an optional method of encoding it. Does anyone see any problems with this? I have been thinking about the suggested on renaming from Ed and looking at XAML. I have decided to use Policy and PolicySet as the replacements for Label/Leaf in this update. However there are still some things that I have not really made any conclusions for. 3. Should we switch from using a simple string, or augment the simple string, by allowing the XACML PolicyCombiningAlgId URIs this means that "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides" and "and" are the same thing. There is no equivalent to "except", but it is also possible this one is a figment of my imagination and there is no real need for it. One can do this in XACML by combining default-permit and default-deny policies but I don't know if it is needed in real life or not. The benefit of allowing the additional URIs is that there are a set of policy combining algorithms already defined by XACML that should correspond to things that are real and it makes it easier to augment the set of combining strings. The downside is that URIs are longer than the set of short strings - does anyone have opinions on this? The other downside of using URIs is that the server may need to give the list of supported combining algorithms to the client or we need to have an error for saying that a combining algorithm is not supported. 4. I am still working my way through the ways of specifying policy options and have not made any decisions for myself let along ones that I would be willing to impose on the document. Any other options and opinions that anyone wants to put in as input, I would be more than willing to get that input at this time. Jim _______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma _______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
