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

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

If you meant to say "we do not need...", that would be incorrect. We can't
add to the original namespace if that's what you're suggesting. Doing that
would mean revising the entire SAML standard and publishing a 2.1, because
the original schema artifact is part of the old publication set.

> [Thinh} When using AttributeStatements, we see the advantage that an
> AttributeStatement can be signed by one issuer, in contrary to an
> Attribute.

Statements can't be signed, only assertions. There's no mention of using
assertions here, and the message can be signed anyway.

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

I don't really like injecting the complexity of assertions into this unless
there's a good reason.

-- Scott

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