Seems we have status codes to address the various potential situations
which addresses my initial concerns.
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).
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?
Mike
-----Original Message-----
From: Scott Cantor [mailto:]
Sent: Thursday, August 05, 2004 9:42 PM
To: SAML
Cc: Beach, Michael C
Subject: On the subject of status codes for "does not support"
Following up further with Mike Beach's question about how a responder
might indicate that it doesn't support a particular SAML feature,
there's also a status code in the spec since prior to last call:
urn:oasis:names:tc:SAML:2.0:status:RequestUnsupported
Again, I don't know how a requester would even know where to send such a
request, but if it just fired one off to an endpoint it knew about that
supported some other profile, this would be one way of responding.
-- Scott
