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: On the subject of status codes for "does not support"

> I don't see this as an issue, but I continued to be confused by Scott's
> comment below about a requester not knowing where to send such a
> request.  The comment suggests that each kind of SAML request/assertion
> would be sent to a different endpoint (probably URL in my mind).

There is no requirement either way, but the metadata is designed such that
each profile is specifically articulated with its endpoint. So if you don't
support a profile, there's no endpoint to find.

This assumes you have accurate metadata. If it's stale, then sure, anything
could happen if the endpoints are shared, so I concede the point.

And no, I don't favor shared URLs for this stuff, I just think it's against
the spirit of what a URL means.

> However, I was thinking of an alternative implementation where the SAML
> responder was a single endpoint that handled all incoming SAML
> requests/assertions.  Seems in that case, there may be a higher
> probability that the responder might get a request/assertion that it
> could not or would not handle.  That was my reasoning behind the
> question about status codes.
> Am I missing something here?

Let me ask the question back, if one assumes metadata is not being used, in
any form roughly comparable to SAML's, then at some point you have to tell
the requester at configuration time where to send the messages, right? Why
would you tell it it could send messages for profile X to endpoint Y if it

All I'm saying is that it's not the *common* case, IMHO.

-- Scott

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