[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] metadata and an ISSUE for 1.1 re: use of"source" and "destinatio n"
Re: "I believe the metadata should eventually support more than just the web sso profiles where the source/destination terms aren't quite as ambiguous (although I could still debate that point a bit)."
Arghh... my statement about ambiguity was ambiguous L - the "aren't quite as ambiguous" phrase was recognizing the fact that the web sso profiles use the terms consistently, but other SAML uses are what causes the ambiguity. Specifically, for an AttributeQuery request/response, "source" and "destination" are not as clear. Thus if I'm defining the SOAP Binding Service URL, does it get defined in the source site info or the destination site info.
I know that when we started talking about defining metadata, we said we would start it based on the info learned from the web sso interop. That made sense and Prateek did a great job of getting the ball rolling. However, I didn't think then (nor now) that the metadata was thus just going to be limited to web sso usage. I would really like to see the metadata encompass the various uses (not just sso) for which SAML can be used.
Source and destination are not terms defined in our glossary and as I mentioned, I think we should make sure they aren't used in the specs. When we talk about metadata related to assertions, I think we should use terms "asserting party" and "relying party". When we talk about protocol metadata, I think the terms should be "requester" and "responder" (yes - my thinking has evolved on this a bit since my original mail).
I'd like to have a discussion on this topic at the next meeting.
Rob Philpott -----Original Message-----
I think it's useful to break out the discussion on this point to its own thread... ----------------------------------
---------------------------------
I feel that the use of the terms "source" and "destination" are too ambiguous to be used in our documents and believe they should be changed to "asserting party" and "relying party". Moreover, I think this should be done for V1.1 in both the Bindings and Profiles document and in the metadata (and anywhere else the terms are used). It's really just a semantics issue. But whenever we can use unambiguous terms (i.e. AP and RP) instead of potentially ambiguous terms, then I think we should do it. To illustrate my point...
In the current B/A Profile, we refer to the Asserting Party where the inter-site transfer service resides as the "source" site. We refer to the Relying Party as the "destination" site. So in this profile, it is the destination site that initiates a SAML Protocol exchange (samlp:Request) with the source site to retrieve an assertion.
But in the case of a general SAML Authority responding to an Attribute Query or an Authz Query, I think of the site where I initiate a query as the "source" site and the site responding to my query as the "destination" site.
Thus in one case the system where the SOAP Binding Service resides is the source site and in the other case it is the destination site. I find this to be ambiguous. I've run across this same issue before in other protocol work and find it is always better to use unambiguous terms where they exist. We do have unambiguous terms - Asserting Party and Relying Party.
In the original work on the Bindings and Profiles document, was this issue previously raised and dismissed? I haven't searched the mail archive to look for anything on this.
In V1.0, it really was just a semantics issue with respect to the text of the document. But with the metadata now being defined, the issue is making its way into a schema definition and that's really where I think we must be as unambiguous as possible. I believe the metadata should eventually support more than just the web sso profiles where the source/destination terms aren't quite as ambiguous (although I could still debate that point a bit).
Thoughts? Rob Philpott -----Original Message-----
Rob,
I am starting a thread with your message as some of your suggestions have pretty broad scope and we need to wrestle with them a little before we are ready to make changes to the meta data document.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC