Tony,
Thanks for the rapid review!
p.2 [for use with WS-Policy] "I assume WS-PolicyAttachment also": I did
not mention WS-PolicyAttachment because I was not aware that Assertions,
Security Tokens, or Attributes appeared in WS-PolicyAttachment
independently of WS-Policy. Is there a dependency I should be aware of?
p2 [client and service requirements?] "So today the emhasis of WS-Policy
is on the service not the client" This profile could be used just to
specify service assertions, but it also supports client assertions,
because those are important to the XACML domain.
p2 "What are "authenticated attributes" ? are these the same things as
"claims" as described in WS-Security?": These are SAML or XACML
Attributes that a Context Handler trusts because they are known to have
been issued by a trusted attribute authority.
p2 "I don't quite understand a "internal XACML policy"": this is the
policy an enterprise actually uses to control access to its internal
resources, i.e. what XACML has been used for traditionally. Such a
policy is often not exposed, at least not in its entirety, to clients
for security and confidentiality reasons. I am assuming that
XACMLAuthzAssertion instances will be exposed as part of the Service's
WS-Policy instances.
p5 [WS-Security and authorization tokens] "Actually these are for
security tokens we don't distinguish between token usages": I will
change this. The actual tokens specified in WS-Security all seem to be
related more to authentication, however, so I am trying to point out the
use for this new token.
p5 [authorization tokens] "Not sure that a UsernameToken can't be used
for Authentication or Authorization, etc. So need to understand what you
are trying to say here.": I will change the reference to WS-Security as
specifying only authentication tokens. This XACML token, however, is
very different from a UsernameToken - it represents an authorization
decision, not an identity.
p5 "It looks like this profile first attempts to define a new type of
token assertion that needs to be recognized and then goes on to talk
about the assertions.": I will try to clarify that the profile defines
three independent aspects of how XACML might be used in a Web Services
context: 1) a way to use an XACMLAuthzDecisionStatementType instance as
an authorization token, 2) a new Assertion for specifying policies, 3)
ways to convey Attribute values that a service PDP's Context Handler
might use in evaluating XACML policies related to a Web Services message.
p5 [Another Web Service may operate on a constrained device that is
unable to run a Policy Decision Point] "This assumes that end points
have a notion of identity, which is not the case today": I don't
understand the connection.
p5 [XACML authorization token] "I assume that this would be in addition
to other tokens": Yes.
p5 [service verifies that the token correctly describes the controlled
access that the client invocation requires] "I also assume that the
endpoint also has a policy that it must intersect with the client's
policy": Usage of this authorization token and use of policies in
XACMLAuthzAssertions are independent. Neither the client nor the
service may have published an authorization/access control/privacy
policy, but the service might still use an authorization token.
Publishing a policy that states that an authorization token is required
would be one way for a service to let a client know of this requirement;
and a client capable of supplying an authorization token could state
this in its policy; but neither is required.
p5 [client obtains Attributes ... to convey to the Web Service] "So do
we assume that these attributes would take the form of policy". No. I
think I created some confusion by not making it more clear at the
beginning that this profile addresses three completely separate aspects
of usage of XACML in a Web Services context. I will clarify this in the
next draft.
p5 [service includes a requirement in its published Web Services policy]
"So you would expect this to be a policy intersection ?" No. At this
point it is just a policy that includes this requirement among possibly
others. An intersection could be performed between this service's
policy and various potential client policies as part of a decision to
participate in a Web Services interaction, however.
p6 [to see if the request is likely to be authorized when the service is
invoked] "I assume that this is at any level of the service, that is at
the various WSDL subject levels": Yes. It will apply to requests
associated with the attachment point of the WS-Policy instance of which
the XACMLAuthzAssertion is a part.
p6 [how to use XACML SAML Assertions in the context of Web Services] "So
why just SAML, why not have a new token type that just has claims?
Keeping claims in normalized form separately from tokens allows consumer
to not have to support multiple token": Because the SAML Assertion has
already been defined, and other SAML Assertions appear to be in use as
tokens. If there are accepted guidelines against this, and accepted
guidelines for how authorization claims would be formulated, I would be
happy to revisit this.
p8 [how to use a SAML Assertion containing an
XACMLAuthzDecisionStatementType instance as a token] "So this would have
to be profiled somewhere, somehow. Also it seems that we would not
wnat to have to dig into the assertion to figure out that this is a
"authorization" token": I assume that services that require such an
authorization token would specify this requirement as part of their
documentation, and possibly as part of their XACMLAuthzAssertion. I saw
another instance of a SAML Assertion being used as a token, so followed
that lead. I agree that it would be nice to know what type of token it
is, but since you point out that WS-Security defines "security" tokens,
and does not distinguish between "authentication" and "authorization"
tokens, it may be too late to try to create an element name distinction now.
p8 [client MAY use token to convey an authz decision from a trusted 3rd
party to a Web Service] "Endpoints may also need these tokens": I need
more education on "endpoints", as opposed to clients and services in a
SOAP message exchange, and targets or subjects of WS-Policy instances.
I would be happy to broaden the applicability description.
p9 [Web Service MAY choose to publish ... XACML ... policy it will apply
with respect to a particular Web Service target] "So how is this done,
via WS-PolicyAttachment ? I would imagine that we would want a
interoperable way to reference policy. So is this a service wide
policy? How do I subset the policy as these can be very large?": This
is only used as an Assertion in a WS-Policy instance. So however the
WS-Policy instance is used is how this Assertion would be used to
publish the policy. It should be the policy that applies to the
target/subject associated with the WS-Policy instance of which it is a part.
p9 [Two instances of XACMLAuthzAssertion MAY be matched to determine
whether they are compatible, and, if so, which requirements and
capabilities are compatible] "intersected": Yes, intersection is the way
they are matched. I was trying to start out without having to explain
intersection, but if you think this would be more clear at this point in
the presentation, I would be happy to change or add this.
p9 [XACMLAuthzAssertion/Requirements/,
XACMLAuthzAssertion/Capabilities/] "Why are these elements and not
attributes ?" Because the content of the two has different forms, and
because I want a single XACMLAuthzAssertion in any given WS-Policy
alternative that can be matched against the single XACMLAuthzAssertion
in any other WS-Policy alternative (at the level of recognition that an
XACML policy is involved) without the generic policy engine having to
match domain-specific attributes.
p9 [There SHALL be no more than one XACMLPolicyAssertion included in any
one wsp:Policy alternative] "Why this limitation as this will lead to
having way too many policies": In most cases, I expect the policies
using the