[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]