RE: [security-services] Comments on sstc-saml2-attribute-management-protocol-01

["Nguyenphu, Thinh (NSN - US/Irving)" <thinh.nguyenphu@nsn.com>]

Hi Scott,

Sorry for late response. I was busy with another project.  My responses,
[Thinh], are below. 
Thinh

-----Original Message-----
From: ext Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Sunday, February 21, 2010 2:10 PM
To: 'OASIS SSTC'
Subject: [security-services] Comments on
sstc-saml2-attribute-management-protocol-01

The major issue I have with the content as a whole is that I agree with
a
comment made by Oracle that this needs to have, at minimum, semantics
for
create/update/delete at the value level. Otherwise it's useful only for
a
subset of attributes, but more importantly I think it would lead to
deployers contorting their attribute definitions to conform with the
limitations of the protocol. I would like to know what others think
about
that issue.

[Thinh] There is two parts to above comments.  1) missing schema and
semantic with the existing  proposal. 2) other capability based on
Oracle comment.

1) Agreed to add schema and semantic to the existing proposal.
2) Perhaps, Oracle has better insight to reponse to this part.
========================================
Separately, I have a number of specific comments. This isn't exhaustive,
as
there a number of fundamental issues with this before it could be
considered
for CD.
 
Document will need to define both the protocol and specific profile(s)
using
it, because conformance requires profiles. An example of this is found
in
the Identity Provider Discovery Protocol and Profile document. It's
somewhat
redundant but necessary for consistency.

[Thinh] Agreed, I will update our draft in next version.
==========================================
Document also needs a conformance section before it can proceed, which
would
need to be expressed in terms of one or more profiles defined in it.

[Thinh] Agreed.
==========================================
Document needs XML namespace assigned, it's not in this draft. Suggest
urn:oasis:names:tc:SAML:2.0:profiles:attribute-management

[Thinh] My understanding based on our proposal, we do need to define a
new namespace.  Because, we just extend the existing SAML protocol
schema.
==========================================
A number of the references seem unnecessary, and at least a couple are
out
of date.

[Thinh} Agreed. I will update our draft.
==========================================
The reference links in the document don't appear to be functional, as
though
they were entered only as text and not actual references.

[Thinh] Agreed.
==========================================
The document seems to omit any reference to Bindings, which will be
necessary in documenting a profile of the protocol.

There's no schema here that I can see. You can't take this forward until
one
is defined for these messages, including both snippets in the draft and
a
stand-alone schema.

To the extent that it's limited to this current "set all values"
semantic, I
question the use of the <AttributeStatement> element in the examples
rather
than just expressing the sequence of <Attribute> elements directly.
Statements have a specific purpose in the schema, and I don't think it's
a
good idea to reuse them here.

[Thinh} When using AttributeStatements, we see the advantage that an
AttributeStatement can be signed by one issuer, in contrary to an
Attribute. If a SP sends a signed AttributeStatement to an IdP, then the
IdP is enabled to know who is the issuer of this AttributeStatement. Can
you elaborate on the reasons for your preference?
==========================================

Much of the security section should be addressed by moving such language
to
normative statements about the use of bindings. For example, "The
requester
MUST authenticate itself to the responder and ensure message integrity,
either by signing the message or using a binding-specific mechanism."
Such
language can be found throughout the SAML Profiles document.

[Thinh] Agreed. 
==========================================
The specification mentions XML Encryption of the messages, but SAML does
not
allow for that at the protocol layer. If use of EncryptedAttribute is
deemed
too inefficient, additional schema work needs to be done here to address
that requirement.

-- 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