RE: WS-Trust question re: token validity periods

[Anthony Nadalin <tonynad@microsoft.com>]

So why the <wst:Lifetime> element was added (and was optional) was 3 fold, 1) some token formats don't have the ability to specifically lifetime, 2) tokens were to be opaque to WS-Trust, thus wanted a way to be able to tell if he token had expired w/o having to pull apart and understand the token to determine the expiration date, 3) wanted a way to have the STS have its own policy (as you point out).

-----Original Message-----
From: robert.philpott@rsa.com [mailto:robert.philpott@rsa.com] 
Sent: Tuesday, January 05, 2010 2:53 PM
To: ws-sx@lists.oasis-open.org
Subject: [ws-sx] WS-Trust question re: token validity periods

Hi folks,

This question stems from an energetic debate I'm having with a colleague about dealing with token validity periods, particularly when SAML tokens are involved.  They have only been supporting SAML tokens to date and have been strictly relying on the assertion validity period as defined by the NotBefore/NotOnOrAfter conditions for validity period semantics of the WSS SAML token.  They have not been including <wst:Lifetime> elements in the RSTR.
	
I recently pointed out that they really should be using the <wst:Lifetime> elements in RST/RSTR's to define the expiration semantics of the tokens since:
a)	WS-Trust defines support for token expiration/renewal, etc, so
it should thus be processed at the WS-Trust layer, not a token-specific layer
b)	The spec states that tokens should be treated as opaque... i.e.
an implementation should not have to parse down inside the token to do it's WS-Trust processing
c)	When they support other token types in the future, those token
types may have no internal mechanism for expressing validity period semantics.  

This then led to a point of disagreement.  

My colleague contends that since the <wst:Lifetime> element is optional and not really a part of the actual token, it is more advisory in nature and is just a convenience for WS-Trust processing. He maintained that if it is present and the token is a SAML token, then the lifetime element should ALWAYS represent the same validity period as expressed by the embedded SAML assertion conditions.  

I argued that was absolutely NOT the case and that such relationships are completely within the realm of some application profile of use.
Yes, a service provider that's handed a SAML token may also need to also ensure that the SAML assertion is itself "valid", but I argue that this is a separate issue from dealing with "token expiration" at the WS-Trust level.

I also pointed out that while a particular application-specific profile of WS-Trust/SAML MAY include some constraints that tie the two together,
neither the WS-Trust spec nor the SAML Token Profile specs do that.   I
argued that it is perfectly valid for an STS to have its own policies regarding token lifetimes during issuance/renewal that can be completely independent from the assertion lifetime policies of a SAML authority from which the STS might obtain assertions to use in its SAML tokens.  

For example, I see no reason that a SAML authority couldn't generate assertions with longer validity periods but an STS that uses that SAML authority only gives out short-lived WSS tokens using that assertion.
If necessary, an STS client can use the WS-Trust renewal binding to obtain a new token when the current one expires (where expiry is defined by the <wst:Lifetime>). The renewed token returned in the RSTR can even use the same long-lived assertion. The RSTR simply includes updated expiration semantics defined by the <wst:Lifetime> element.  I tried to argue that this is analogous to issuing short-lived tokens using an X509 certificate binary token.  My certificate can be very long-lived but I probably don't want any WSS tokens issued with that cert to have an expiration period matching the cert. 

My colleague isn't convinced and believes that the SAML assertion expiration should always reflect the WSS security token lifetime. I contend that he is allowed to define that in his application-specific profile, but that is not the intent of either the WS-Trust or SAML Token Profile spec.
	
I offered to query the TC for other opinions, so here it is :-).

Thanks,

Rob Philpott
RSA, the Security Division of EMC
Senior Technologist | e-Mail: robert.philpott@rsa.com <rphilpott@rsa.com>  | Office: (781) 515-7115 | Mobile: (617) 510-0893



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php