OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi Scott,

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

-----Original Message-----
From: ext Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Sunday, February 21, 2010 2:10 PM
Subject: [security-services] Comments on

The major issue I have with the content as a whole is that I agree with
comment made by Oracle that this needs to have, at minimum, semantics
create/update/delete at the value level. Otherwise it's useful only for
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
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,
there a number of fundamental issues with this before it could be
for CD.
Document will need to define both the protocol and specific profile(s)
it, because conformance requires profiles. An example of this is found
the Identity Provider Discovery Protocol and Profile document. It's
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
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

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

[Thinh} Agreed. I will update our draft.
The reference links in the document don't appear to be functional, as
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
is defined for these messages, including both snippets in the draft and
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
than just expressing the sequence of <Attribute> elements directly.
Statements have a specific purpose in the schema, and I don't think it's
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
normative statements about the use of bindings. For example, "The
MUST authenticate itself to the responder and ensure message integrity,
either by signing the message or using a binding-specific mechanism."
language can be found throughout the SAML Profiles document.

[Thinh] Agreed. 
The specification mentions XML Encryption of the messages, but SAML does
allow for that at the protocol layer. If use of EncryptedAttribute is
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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]