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"

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?


-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Thursday, August 05, 2004 9:42 PM
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:


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

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