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