Re: [imi] Issue regarding AppliesTo content

[Anthony Nadalin <drsecure@us.ibm.com>]

So I think that this is already covered in the Web Services Addressing Endpoint References and Identity specification as there are extensions there to add SPN

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

"Scott Cantor" ---02/05/2009 03:42:31 PM---The possible addition I raised on the call pertains to the wsp:AppliesTo

From:	"Scott Cantor" <cantor.2@osu.edu>
To:	<imi@lists.oasis-open.org>
Date:	02/05/2009 03:42 PM
Subject:	[imi] Issue regarding AppliesTo content

---

The possible addition I raised on the call pertains to the wsp:AppliesTo
element used to express "Token Scope", which is covered most exhaustively in
3.3.3 of the latest draft. This is of course used as the auditing vs.
non-auditing distinction. My suggestion relates to the auditing case.

The issue I'm raising is the two different interpretations of this element
depending on how the RP expresses its policy to the selector, and what it
includes in the policy. The two different interpretations I'm referring to
are the idea of the endpoint location vs. the "identity" of the RP.

In many, if not most, cases today, I am led to understand that the usual
practice is for the selector to place the RP's endpoint location into
wsp:AppliesTo. This is called out in the second row of the table, in which
the IP/STS requires the element, and the RP doesn't include the element in
its policy. In the other cases in which it's sent, the value is set by the
RP's policy document explicitly, so whether it's the location or some other
identifier is up to the RP.

The issue I have is that for some implementations of these sorts of
technologies, there's a distinction between location and identity. In SAML,
this is explicit because we created the concept of an entityID, an
identifier that is not necessarily required to be similar to or overlap with
any particular protocol endpoint. This is important for a lot of reasons:

- it allows clean naming and policy referencing of entities without being
subject to where particular services happen to be deployed

- it assists with multi-protocol deployments

- it allows many endpoints to be exposed by a single logical entity,
including endpoints on different virtual and physical hosts

Etc.

Note that this same concept comes up on the IP/STS side, as on line 246
referring to the <wsa:Address> element identifying the token issuer:

"A Relying Party MAY specify the value of the sp:Issuer/wsa:Address element
in policy as a "logical name" of the token issuer instead of an actual
network address where the token is issued."

Same idea, just the reverse. There are implementation strategies for things
like distributing and looking up encryption keys that can rely on metadata
about the RP, but this is somewhat easier if the wsp:AppliesTo element names
the RP, rather than points to a location at the RP.

Now, my suggetion. The reason the location gets used moreso than a logical
identifier is at least in part because the <OBJECT> markup approach for
using the profile on a web site does not allow for supplying the value of
wsp:AppliesTo. In effect, using the markup approach today implies that
you're on line 2 of that table in 3.3.3. You generally won't have a policy
document, thus no RST template, thus no wsp:AppliesTo.

My suggestion is just to add an OPTIONAL field to section 11.2, Identity
Selector Invocation Parameters:

---
11.2.8 appliesTo (optional)

This parameter specifies a value to be placed into the <wsp:AppliesTo>
element in the selector's Request Security Token (RST), if directed to do so
by the rules in section 3.3.3.
---

That's a start anyway. I'd be happy to propose additional clarifying text
connecting that to the "template-in-policy" case or adjusting other wording,
if the idea is acceptable.

Unless I'm missing something, I think this is just the equivalent of what
the policy-based option already allows, the RP to control the string that
identifies it to the IP/STS (where the point of that control is to align
with some existing naming scheme that means something to the IP/STS).

(I realize this is a change on the selector side in the sense that nothing
today would recognize it, that's why I asked about the timing of proposing
it.)

Comments?

-- Scott



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php