Present: Charlton Barreto, Glen Daniels, Frederick Hirsch, Daniel Roth,
Glen wants to mark informational assertions
as optional to accommodate requestors who are unaware of these assertions. Umit wants to clarify section 4.4 - Policy Intersection
(fix paragraph 2 in sec.4.4 to clarify what domain specific processing allows
you to do). Disagreement - the applicability of optional marker for
informational assertions.
a) Provider always logs. Provider
uses an assertion whose semantics is: FYI - I am logging.
b) Provider always use a prescribed privacy policy. Provider uses an assertion
whose semantics is: FYI - here is my privacy notice.
For these assertions, there aren't
any behavioral requirements on the provider or the requestor. Requestors don't
have to understand. Provider wants to advertise these assertions and didn't
want to block requestors that use intersection. (Is this a behavior or
requirement or information? Asir: close to just a piece of information)
Requestors don't have to use
intersection. When requestors use intersection, they know what their capabilities
and requirements are and they have sufficient info to compute compatibility
with any policy.
Providers should not lie. Assertions
can be marked optional to represent behaviors that may be engaged. Assertions
should not be marked optional to represent behaviors that are always engaged.
Explored the use
of a new marker 'ignorable' to signal ignorable assertions. Ignorable is an attribute, whose type is xs:boolean, that can be used on
assertions. Requestors may ignore ignorable assertions.
Considered two sets of policy alternatives:
c) Alternative 1 = (A, B) and
Alternative 2 = (A, B, C - ignorable)
d) Alternative 3 = (A, B, C) and
Alternative 4 = (A, B, C - ignorable)
e) Requestors who prefer to engage a
known set of behaviors and want to ensure that a provider uses the same set of
behaviors. From this point of view, alternative 1 and 2 are incompatible;
alternative 3 and 4 are compatible. That is, a strict form of compatibility.
f) Requestors who prefer to engage a
known set of behaviors and are tolerant to any ignorable behaviors advertised
by a provider. From this point of view, alternative 1 and 2 are compatible;
alternative 3 and 4 are compatible. That is, a lax form of compatibility.
g) Augment the policy data model – A
policy assertion may indicate whether it can be ignored opportunistically by
some requestors using a new boolean
property 'ignorable'. The default value of the 'ignorable' property is false.
[This new property unpacks a small
piece of semantics that is packed into the QName of
an assertion into a machine readable form.]
h) Introduce a new marker - ‘wsp:Ignorable’ is an attribute whose type is xs:boolean.
Omitting this marker is semantically equivalent to including it with a value of
false. Assertions can be marked as ignorable to represent assertion with no
meaningful behavior or requirement.
i) Changes to the
intersection algorithm - Intersection has two modes: strict and lax. Requestors
may use either modes.
If strict mode,
For two policy alternatives to be compatible, they must at least have the same
policy alternative vocabulary. ... Two policy alternatives are compatible if
each assertion is compatible with an assertion whose behavior in the other
alternative and vice versa.
If lax mode,
For two policy alternatives to be compatible, they must at least have the same
policy alternative vocabulary ignoring any ignorable assertions
opportunistically. ... Two policy alternatives are compatible if each assertion
that is not ignorable with an assertion in the other alternative and vice
versa.
1) What is domain specific
processing? List of options (decide out of band, on the user, contact the
assertion author and ask if it can be ignored).
When doing intersection, domain
specific processing is additional intersection processing done based on the semantics
of the assertions in the intersected policies.
No ordering is specified.
2) How do you do intersection if you
don't recognize a QName?
You can use the current intersection
algorithm to know that the unknown behavior is not applicable. If the assertion is marked ignorable, you
could use lax mode.
3) Section 4.4 (Policy
Intersection), paragraph two uses 'domain-specific' and 'domain independent'
processing. Does the order of domain-specific and domain-independent processing
matter?
No
4) Don't use requestor/provider in
any proposed text.
This is guidance from CA\Yakov for
any concrete proposal that may stem out of this treasure hunt.
5) When should you use the
optional marker on an assertion?
See - accepted guidelines for issue
3564.
6) How can a provider include
informational assertions in a policy? assertions that
have no wire manifestations?
Use 'wsp:Ignorable' marker. Use multiple policies on different
endpoints. Use wsp:Optional if the assertion specifies no behavior.
j) Why would an assertion be used to
represent a non-behavior or non-requirement or non-capability or non-condition
or an advertisement?
k) Why should a provider tell
requestors to ignore?
l) Why would a requestor respect
'ignore' directives from a provider?
m) If a requestor doesn't understand
an assertion why would a requestor ignore the assertion? If a contract signer
doesn't understand some of the terms and conditions why would the signer sign a
contract?
n) Who should sanction the use of
the ignorable marker on an assertion? (assertion
author, provider, etc.)
o) What are the guidelines for using
this new marker?
p) When should you use lax mode
intersection?