[this is a response to ostensibly "substantive" comments wrt the sip-saml draft]
Marcos Dytz <[EMAIL PROTECTED]> said (via Hannes):
>
> 1) I believe that it would be good to leave a bit the emphasis on
> authentication and providing different uses of the protocol
Sebastian Felis said (via Hannes):
>
> In my point of view, the draft focuses only on trait-based
> authorization and tries to deploy trait-based authorization using SAML.
> It does not try to specify SAML over SIP, which I was expected.
I'm assuming that both of the above are essentially saying:
Perhaps the SIP SAML Profile should be generalized so it may be applied
to other use cases in a SIP context.
yes?
This spec is presently designed for a fairly narrow use case, derived from
RFC4474 "SIP Identity", and RFC4484 "Trait-Based Authorization Requirements for
SIP". This use case is summarized in section 4 of draft-ietf-sip-saml-02 like so..
4. Specification Scope
The scope of this specification is:
o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such
that a subject's profile attributes, and their domain's
certificate, can be conveyed to a relying party using SAML. In
doing so, satisfy the requirements outlined in [RFC4484], and
compose with [RFC4474].
Which arguably leaves essential things unsaid, such as..
- "using SAML" here means "using a SAML assertion", not using one of the
existing SAML profiles. This is a _new_, SIP-specific, SAML profile.
- we're _not_ trying to concoct a fully-general "authorization mechanism"
as imagined in RFC4484. Rather, we're simply trying to provide a means
to convey (some undefined (sub)set of) a subject's profile attributes
in the specific context of "authenticated identity management" as defined
in RFC4474. As such, -sip-saml-02, presently meets (only) a subset of
the requirements in RFC4484. For example, Requirement 3 of Section 5 of
RFC4484 stipulates that an authorization assertion must be deliverable
to a SIP UAC either by reference or by value, and -sip-saml-02
presently defines by-reference only.
- enhancing -sip-saml-02, meaning the "SIP SAML Profile", to address
additional use cases, and/or fully meet RFC4484's requirements,
would add significant complexity to the specification.
So, if the WG were to decide that -sip-saml-02 ought to, at this time, address
additional use cases, and/or fully meet RFC4484's requirements, then we need to
do yet more significant work on it. Otherwise, it seems fairly close to being
complete.
Thoughts?
=JeffH
ps:
Just to clarify on this comment..
> It does not try to specify SAML over SIP, which I was expected.
This seems to me to be indicative of a misunderstanding of SAML, because the
phrase "SAML over SIP" doesn't make much actual sense. SAML per se is not "just
a concrete protocol" that can be simply layered above another protocol, as HTTP
is layered over TCP. Rather, it's a _framework_, that must be profiled for
particular contexts of use, e.g. SIP Authenticated Identity Management.
Sometimes folks, when thinking of SAML, are thinking of just one of the
existing SAML profiles (e.g. Web SSO) and imagining that to be "SAML" or "the
SAML protocol", and further imagine said "protocol" somehow being layered over
some other protocol. This line of thinking wrt SAML isn't workable. Rather one
needs to think in terms of making use of applicable pieces of SAML's "abstract
classes" (in the "SAML core" specification) and freshly concretely applying
them to the target use case and protocols, thus crafting a new SAML profile(s)
(and binding(s)) -- which is exactly what -sip-saml-02 does.
See also..
How to Study and Learn SAML
http://identitymeme.org/how-to-study-and-learn-saml/
---
end
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
