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] Groups - sstc-saml-x509-authn-attrib-profile-draft-10-diff.pdf uploaded

On 8/29/06, Ari Kermaier <ari.kermaier@oracle.com> wrote:
> Proposing metadata extensions to make implementing this profile easier is fine. But saying that users of metadata MUST employ those extensions to be conformant with this profile is not OK at this point, IMO.


> In any case, it seems to me that a better idea would be to propose general-purpose metadata extensions -- in a metadata extension spec -- that could be used to facilitate the X.509 attribute profile.

In light of the comments you and Scott have made with respect to
metadata, and after reviewing the metadata requirements as currently
written, it's pretty clear the latter need to be factored out into a
separate profile.  As you say, entities supporting the attribute query
profile can choose to support the metadata profile or not as the case
may be.

> For example, extending metadata to allow providers to call out whether they support/require encrypted NameIDs, Attributes and/or Assertions might be a good thing.

Actually, I see this as a separate issue altogether, so I'll start a
new thread along these lines.

> But requiring that a profile specific attribute like hasEnhancedSupport be used puts an unnecessary burden on a general-purpose attribute responder.

Agreed.  A separate metadata profile should address this issue, correct?


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