[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Transient IDs and SAML Conformance
Are we saying that in order to be SAML 2.0 IDP/SP conformant, every implementer must support transient and persistent id formats completely. Specifically this includes:
- An IDP can successfully respond with assertion responses to authn requests that contain NameIDPolicy name id format requests of "...transient "(where the value/xml format follows the SAML specs).
- An SP can successfully accept an assertion who NameID format is "...transient". For example, iniiated by an unsolicited Saml SSO login at the IDP.
- An SP can successfully create an implementation specific web session for the transient user (however this is done). The main point being that the transient user can obtain access to some protected resources that cannot be accessed without some type of authntication at the SP.
- An SP (or IDP) can generate a SAML SLO operation (user initiated, for example), such that the a Single Logout message can be sent to the IDP (or SP) identifyinig the transient name if format and value as well as the SAML session index.
- An SP (or IDP) can process a SAML SLO request from an IDP (or SP) whose NameID uses theh previously created transient name if format and value as well as the SAML session index.
Does everyone agree that the above stmts would be true of ANY SAML 2.0 conformant IDP/SP implementation?
> -----Original Message-----
> From: Scott Cantor [mailto:firstname.lastname@example.org]
> Sent: Friday, September 16, 2005 1:08 PM
> To: 'Eric Tiffany'; 'SAML'
> Subject: RE: [security-services] Transient IDs and SAML Conformance
> > I guess I would say that the definition of "process" here
> needs to be a
> > tighter --- and for a conformance spec, perhaps needs to go
> a bit beyond
> > spec in terms of setting expectations.
> How can it be "legal" to process the ID successfully, and
> then return a SAML
> error? You can't return a SAML error from non-SAML code, so I
> think it's
> unambiguous to say "the SAML layer must successfully process the value
> without returning an error".
> We can't say what happens once the application at the SP gets
> control. But
> that's not a SAML error.
> SAML conformance can't include expectations about that, but I guess a
> conformance testing suite can just to determine whether something is
> > For example, with a Persistent ID, an implementation might
> claim to be
> > conformant even though it rejects all Persistent IDs ---
> but that would
> > eliminate the possibility of Single-Logout or NameID Management.
> Single Logout has nothing to do with persistent IDs, it works with any
> format because it's session-based.
> NameID Mgmt does, and no, you can't just ignore the messages
> by returning
> errors. But how can we control how somebody implements them?
> As I said at
> the time, I am within my rights to provide nothing but an
> API, and then at
> conformance test time, supply a dumb plugin that writes to a
> file, and is
> totally unsuitable for production use. Conformance can't
> determine quality.
> -- Scott
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all
> your TCs in OASIS