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: The policy issuer identifier issue


I promised at the TC call today to write up the alternatives to the
issue regarding the policy issuer, whether it should be required or not.

(Old thread is here:

There are two issues here (which are closely related).

1. How do we define the processing model in the spec document?

2. Do we make the <PolicyIssuer> element in the schema mandatory for 3.0

Regarding the processing model description, the spec is currently
written such that it refers to a specific identified trusted issuer and
also states if an XACML policy does not contain an issuer, this is
equivalent to the identified issuer.

There are three alternatives:

A) My observation is that we can simplify the spec text and remove a
couple of paragraphs of text by dropping this explicit issuer reference.
Benefit: Shorter spec.

B) An alternative option is that we always require an issuer. Benefit:
More consistent policy files.

C) We leave it optional as it is now. As Hal said, the benefit here is
that we don't have to make up our mind. :-)

Regarding issue 2, I think it is worth considering the potential for
interoperability issues for policies signed according to the SAML
profile. (Or signed by some other means.)

The SAML profile allows wrapping an XACML policy inside a signed SAML
assertion. The signature of the assertion could be interpreted as the
issuer of the policy. In this case the issuer element of the policy can
be derived from the SAML signature (how to do this in detail of course
needs to be specified).

If we do this derivation, we can use the SAML profile in two ways.
First, we could leave out the issuer from the enveloped policy document
and say in the SAML profile spec that the XACML policy issuer is derived
from the SAML signature.

Alternatively we could say that there is an XACML issuer element, but it
has to match the XACML issuer which can be derived from the SAML signature.

If we use the first option, we should make the policy issuer element
optional in the schema since otherwise the wrapped XACML document cannot
be validated against the schema. If we specify this mode of operation in
the SAML profile, we really have to allow this in the XACML schema.
Otherwise people cannot validate the policies against the standard XACML
schema, and they need to make their own schema for signed policies which
do not contain an issuer. If people start making their own schemas we
have an interoperability issue for exchange of signed policies.

Even if we do require the explicit trusted issuer in the processing
model, we could leave the issuer element optional in the schema with the
explanation that this is intended for policies in transport or storage
where the issuer is defined by the context, for instance a signature.

My preference is to drop the trusted issuer since it simplifies/shortens
the specification text, which is a good thing. I can live with any
alternative since this is not a big deal since it really affects only
tools and implementations, not users or functionality.

I have added the SAML signature translation as a new issue: 86. SAML
profile: Policy issuer and id of signed policies


Best regards,

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