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


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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

Subject: RE: [saml-dev] use of protocolSupportEnumeration

> This works fine for a single profile but what if a single
> AttributeService wishes to support multiple profiles?  It will tend to
> get a little ugly.

First, I think the whole problem here is that if you could support multiple
profiles at the same location, you wouldn't need to care much about this at
all. But I'm not sure what's ugly about it. It's just XML, no uglier than
any other.

> Why not specify attribute profileSupportEnumeration?

Because I can't search that. People can do a simple XPath for my approach. I
don't like the enumerations. I inherited it from ID-FF, I just didn't change
it on the theory it wouldn't be used much.

> You mean multiple AttributeService elements in IdP metadata?  This
> would work but I'll bet they all look similar except for the endpoint
> location.

So? How else are you going to tell the difference?

> In the AttributeQuery on a per-transaction basis?  I'm not sure that's
> necessary if the appropriate endpoints are called out in IdP metadata
> (as you suggest).

That's the point. You have to pick something. If I have an enumeration on
both sides that overlap with more than one profile, how can I tell? They're
all the same answer, they just solve the problem in different ways.

The simple answer to your question is that if a profile lacks a discussion
of metadata requirements, then for all intents, it's not using metadata
interoperably. I've made sure to deal with that issue in all the work I've
done. If I had the time to look at the profile in question, I would have
noted it, so you probably should.

-- Scott

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