[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"
Agreed. -----Original Message----- From: Scott Cantor [mailto:firstname.lastname@example.org] Sent: Friday, August 06, 2004 12:26 PM To: Beach, Michael C; 'SAML' 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 can't? All I'm saying is that it's not the *common* case, IMHO. -- Scott