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


Subject: RE: [security-services] Question regarding SAML error codes...


I would agree that it would be very useful to have a rcihers set of error
codes associated with SAML processing.
 
Infact, if these new error codes could also be applicable to SAML/SOAP
binding (which WSS TC is working on) that would help error processing
interop for SOAP/SAML apps as well.
 
thanks,
Zahid

-----Original Message-----
From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
Sent: Monday, February 03, 2003 2:31 PM
To: 'rphilpott@rsasecurity.com'; 'pmishra@netegrity.com'
Cc: 'security-services@lists.oasis-open.org'
Subject: [security-services] Question regarding SAML error codes...



Hi, 

I recently received a question from a SAML developer regarding error codes.
Specifically, the developer was asking for 

"...more detailed error information. Saml 1.0 leaves most of it to the
vendors, which means automated error recovery (and possibly troubleshooting)
is going to be difficult in multi-vendor environments."

When I asked for examples of what would be helpful, I got the following
response: 

I think there could be a code for each item in the message that might fail.
Currently, the only specific error codes have to do with version mismatches
and one about too many elements to be returned. 

*	digital signature validation failed (could get more specific wrt
unknown signer DN, cryptographic problems, etc) 

*	missing digital signature 

*	bad artifact 

*	unknown sourceID 

*	unknown/expired assertionHandle (perhaps this isn't an error... for
some reason, you're supposed to return "success" even if you can't/won't
generate an assertion. I think there are different subcases here, and some
are errors) 

*	request issueInstant is in the future 

*	request issueInstant is too far in the past (these two indicate a
clock sync problem) 


Would it be possible to discuss this briefly on tomorrow's call and see if
there's any desire to include something along these lines in the 1.1 time
frame?

Carlisle. 



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


Powered by eList eXpress LLC