< draft-schaad-plasma-service-02.txt		draft-schaad-plasma-service-03.txt >
	Network Working Group J. Schaad		Network Working Group J. Schaad
	Internet-Draft Soaring Hawk Consulting		Internet-Draft Soaring Hawk Consulting
	Intended status: Standards Track June 6, 2012		Intended status: Standards Track August 24, 2012
	Expires: December 8, 2012		Expires: February 25, 2013
	Email Policy Service Trust Processing		Plasma Service Trust Processing
	draft-schaad-plasma-service-02		draft-schaad-plasma-service-03
	Abstract		Abstract
	Write Me		Write Me
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 8, 2012.		This Internet-Draft will expire on February 25, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	5.1.2. WS Trust Tokens . . . . . . . . . . . . . . . . . . . 16		5.1.2. WS Trust Tokens . . . . . . . . . . . . . . . . . . . 16
	5.1.3. XML Signature Element . . . . . . . . . . . . . . . . 17		5.1.3. XML Signature Element . . . . . . . . . . . . . . . . 17
	5.1.4. GSS-API Element . . . . . . . . . . . . . . . . . . . 18		5.1.4. GSS-API Element . . . . . . . . . . . . . . . . . . . 18
	5.2. xacml:Request Element . . . . . . . . . . . . . . . . . . 18		5.2. xacml:Request Element . . . . . . . . . . . . . . . . . . 18
	6. Plasma Response Element . . . . . . . . . . . . . . . . . . . 20		6. Plasma Response Element . . . . . . . . . . . . . . . . . . . 20
	6.1. xacml:Response Element . . . . . . . . . . . . . . . . . . 20		6.1. xacml:Response Element . . . . . . . . . . . . . . . . . . 20
	7. Role Token and Policy Acquisition . . . . . . . . . . . . . . 23		7. Role Token and Policy Acquisition . . . . . . . . . . . . . . 23
	7.1. Role Token Request . . . . . . . . . . . . . . . . . . . . 23		7.1. Role Token Request . . . . . . . . . . . . . . . . . . . . 23
	7.2. Request Role Token Response . . . . . . . . . . . . . . . 24		7.2. Request Role Token Response . . . . . . . . . . . . . . . 24
	7.2.1. RoleToken XML element . . . . . . . . . . . . . . . . 25		7.2.1. RoleToken XML element . . . . . . . . . . . . . . . . 25
			7.2.2. Email Address List Options . . . . . . . . . . . . . . 28
	8. Sending An Email . . . . . . . . . . . . . . . . . . . . . . . 29		8. Sending An Email . . . . . . . . . . . . . . . . . . . . . . . 29
	8.1. Send Message Request . . . . . . . . . . . . . . . . . . . 29		8.1. Send Message Request . . . . . . . . . . . . . . . . . . . 29
	8.1.1. CMS Message Token Data Structure . . . . . . . . . . . 30		8.1.1. CMS Message Token Data Structure . . . . . . . . . . . 30
	8.2. Send Message Response . . . . . . . . . . . . . . . . . . 32		8.1.2. XML Label Structure . . . . . . . . . . . . . . . . . 32
	9. Decoding A Message . . . . . . . . . . . . . . . . . . . . . . 34		8.2. Send Message Response . . . . . . . . . . . . . . . . . . 37
	9.1. Requesting Message Key . . . . . . . . . . . . . . . . . . 34		9. Decoding A Message . . . . . . . . . . . . . . . . . . . . . . 39
	9.2. Requesting Message Key Response . . . . . . . . . . . . . 35		9.1. Requesting Message Key . . . . . . . . . . . . . . . . . . 39
	10. Plasma Attributes . . . . . . . . . . . . . . . . . . . . . . 37		9.2. Requesting Message Key Response . . . . . . . . . . . . . 40
	10.1. Data Attributes . . . . . . . . . . . . . . . . . . . . . 37		10. Plasma Attributes . . . . . . . . . . . . . . . . . . . . . . 42
	10.1.1. Channel Binding Data Attribute . . . . . . . . . . . . 37		10.1. Data Attributes . . . . . . . . . . . . . . . . . . . . . 42
	10.1.2. CMS Signer Info Data Attribute . . . . . . . . . . . . 38		10.1.1. Channel Binding Data Attribute . . . . . . . . . . . . 42
	10.1.3. S/MIME Capabilities Data Attribute . . . . . . . . . . 38		10.1.2. CMS Signer Info Data Attribute . . . . . . . . . . . . 43
	10.2. Obligations and Advice . . . . . . . . . . . . . . . . . . 39		10.1.3. S/MIME Capabilities Data Attribute . . . . . . . . . . 43
	10.2.1. Signature Required . . . . . . . . . . . . . . . . . . 39		10.2. Obligations and Advice . . . . . . . . . . . . . . . . . . 44
	10.2.2. Encryption Required . . . . . . . . . . . . . . . . . 39		10.2.1. Signature Required . . . . . . . . . . . . . . . . . . 44
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 41		10.2.2. Encryption Required . . . . . . . . . . . . . . . . . 44
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		11. Certificate Profiles . . . . . . . . . . . . . . . . . . . . . 46
	12.1. Plasma Action Values . . . . . . . . . . . . . . . . . . . 42		12. Message Transmission . . . . . . . . . . . . . . . . . . . . . 47
	12.2. non . . . . . . . . . . . . . . . . . . . . . . . . . . . 43		13. Security Considerations . . . . . . . . . . . . . . . . . . . 48
	13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 44		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45		14.1. Plasma Action Values . . . . . . . . . . . . . . . . . . . 49
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 45		14.2. non . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
	14.2. Informative References . . . . . . . . . . . . . . . . . . 46		14.3. Port Assignment . . . . . . . . . . . . . . . . . . . . . 51
			15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 52
			16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
			16.1. Normative References . . . . . . . . . . . . . . . . . . . 53
			16.2. Informative References . . . . . . . . . . . . . . . . . . 54
	Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .		Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
	Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 49		Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 57
	Appendix B. Example: Get Roles Request . . . . . . . . . . . . . 54		Appendix B. Example: Get Roles Request . . . . . . . . . . . . . 62
	Appendix C. Example: Get Roles Response . . . . . . . . . . . . . 55		Appendix C. Example: Get Roles Response . . . . . . . . . . . . . 63
	Appendix D. Example: Get CMS Token Request . . . . . . . . . . . 56		Appendix D. Example: Get CMS Token Request . . . . . . . . . . . 64
	Appendix E. Example: Get CMS Token Response . . . . . . . . . . . 58		Appendix E. Example: Get CMS Token Response . . . . . . . . . . . 66
	Appendix F. Example: Get CMS Key Request . . . . . . . . . . . . 59		Appendix F. Example: Get CMS Key Request . . . . . . . . . . . . 67
	Appendix G. Example: Get CMS KeyResponse . . . . . . . . . . . . 60		Appendix G. Example: Get CMS KeyResponse . . . . . . . . . . . . 68
	Appendix H. Enabling the MultiRequests option . . . . . . . . . . 61		Appendix H. Enabling the MultiRequests option . . . . . . . . . . 69
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 70
	1. Introduction		1. Introduction
	1.1. XML Nomenclature and Name Spaces		1.1. XML Nomenclature and Name Spaces
	The following name spaces are used in this document:		The following name spaces are used in this document:
	+-----+--------------------------------------------+----------------+		+-----+--------------------------------------------+----------------+
	| Pre | Namespace | Specification( |		| Pre | Namespace | Specification( |
	| fix | | s) |		| fix | | s) |
	skipping to change at page 11, line 35 ¶		skipping to change at page 12, line 5 ¶
	structure, the secure transport is responsible for providing the		structure, the secure transport is responsible for providing the
	confidentiality and integrity protection services over the entire		confidentiality and integrity protection services over the entire
	message.		message.
	Multiple dialogs may be run over a single secure transport. Before a		Multiple dialogs may be run over a single secure transport. Before a
	new dialog may be started, the previous dialog MUST have completed to		new dialog may be started, the previous dialog MUST have completed to
	a state of success, failure or not applicable. A new dialog MUST NOT		a state of success, failure or not applicable. A new dialog MUST NOT
	be started after receiving a response with an indeterminate status.		be started after receiving a response with an indeterminate status.
	This is an indicator that the dialog has not yet completed.[anchor14]		This is an indicator that the dialog has not yet completed.[anchor14]
	Plasma compliant implementations MUST support TLS 1.1 [RFC4346] and
	above as secure transports. Implementations SHOULD NOT allow for the
	use of TLS 1.0 or SSL. Other secure transports MAY be implemented.
	5. Plasma Request		5. Plasma Request
	The specification is written using XACML as the basic structure to		The specification is written using XACML as the basic structure to
	frame a request for an operation. The request for operations to		frame a request for an operation. The request for operations to
	occur are written using XACML action items. This specification		occur are written using XACML action items. This specification
	defines actions specific to Plasma in a CMS environment. Other		defines actions specific to Plasma in a CMS environment. Other
	specifications can define additional action items for other		specifications can define additional action items for other
	environments (for example the XML encryption environment) or other		environments (for example the XML encryption environment) or other
	purposes. (Future work could use this basic structure to standardize		purposes. (Future work could use this basic structure to standardize
	the dialogs between PDPs and PAPs or to facilitate legal signatures		the dialogs between PDPs and PAPs or to facilitate legal signatures
	skipping to change at page 20, line 20 ¶		skipping to change at page 20, line 20 ¶
	The XML Schema used to describe the top level response is as follows:		The XML Schema used to describe the top level response is as follows:
	<xs:element name="PlasmaResponse" type="eps:ResponseType"/>		<xs:element name="PlasmaResponse" type="eps:ResponseType"/>
	<xs:complexType name="ResponseType">		<xs:complexType name="ResponseType">
	<xs:sequence>		<xs:sequence>
	<xs:element ref="xacml:Response"/>		<xs:element ref="xacml:Response"/>
	<xs:element ref="eps:PlasmaReturnToken" minOccurs="0" maxOccurs="unbounded"/>		<xs:element ref="eps:PlasmaReturnToken" minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="Version" type="xs:string" default="1.0"/>		<xs:attribute name="Version" type="xs:string" default="1.0"/>
	</xs:complexType>		</xs:complexType>
	<xs:element name="PlasmaReturnToken" type="eps:PlasmaReturnTokenType" abstract="true"/>		<xs:element name="PlasmaReturnToken" type="eps:PlasmaReturnTokenType"/>
	<xs:complexType name="PlasmaReturnTokenType" abstract="true">		<xs:complexType name="PlasmaReturnTokenType" abstract="true">
	<xs:attribute name="DecisionId"/>		<xs:attribute name="DecisionId" type="xs:string"/>
	</xs:complexType>		</xs:complexType>
	A Plasma Response has two elements:		A Plasma Response has two elements:
	xacml:Response is a mandatory element that returns the status of the		xacml:Response is a mandatory element that returns the status of the
	access request.		access request.
	PlasmaReturnToken is an optional element that will return one or		PlasmaReturnToken is an optional element that will return one or
	more PlasmaReturnToken elements. These tokens represent the		more PlasmaReturnToken elements. These tokens represent the
	answer, for a success, of the request.		answer, for a success, of the request.
	A Plasma Return Token is the base type from which return values are		A Plasma Return Token is the base type from which return values are
	derived. The optional attribute Decision is defined for correlation		derived. The optional attribute DecisionId is defined for
	of requests and results in the event that multiple requests are made.		correlation of requests and results in the event that multiple
	This document defines the following items that are derived from this		requests are made. This document defines the following items that
	type:		are derived from this type:
	o RoleToken - used to return roles.		o RoleToken - used to return roles.
			o CMSMessageToken - used to return one or more CMS RecipientInfo
			strucutures.
			o CMSKeyToken - used to return either a CMS RecipientInfo structure
			or a bare content encryption key.
	6.1. xacml:Response Element		6.1. xacml:Response Element
	The xacml:Response element has the ability to return both a decision,		The xacml:Response element has the ability to return both a decision,
	but additionally information about why a decision was not made.		but additionally information about why a decision was not made.
	The schema for the xacml:Response element is reproduced here for		The schema for the xacml:Response element is reproduced here for
	convenience:		convenience:
	<xs:element name="Response" type="xacml:ResponseType"/>		<xs:element name="Response" type="xacml:ResponseType"/>
	<xs:complexType name="ResponseType">		<xs:complexType name="ResponseType">
	skipping to change at page 21, line 36 ¶		skipping to change at page 21, line 39 ¶
	The xacml:Response element consists of the following elements:		The xacml:Response element consists of the following elements:
	xacml:Decision is a mandatory element that returns the possible		xacml:Decision is a mandatory element that returns the possible
	decisions of the access control decision. The set of permitted		decisions of the access control decision. The set of permitted
	values are Permit, Deny, Indeterminate and No Policy.		values are Permit, Deny, Indeterminate and No Policy.
	xacml:Status is an optional element returned for the Indeterminate		xacml:Status is an optional element returned for the Indeterminate
	status which provides for the reason that a decision was not able		status which provides for the reason that a decision was not able
	to be reached. Additionally it can contain hints for remedying		to be reached. Additionally it can contain hints for remedying
	the situation. This document defines a new set of status values		the situation. This document defines a new set of status values
	to be returned. Formal declaration may be found in Section 12.		to be returned. Formal declaration may be found in Section 14.
	* gss-api indicates that a gss-api message has been returned as		* gss-api indicates that a gss-api message has been returned as
	part of the authentication process.		part of the authentication process.
	xacml:Obligations is designed to force the PEP to perform specific		xacml:Obligations is designed to force the PEP to perform specific
	actions prior to allowing access to the resource. If a response		actions prior to allowing access to the resource. If a response
	is returned with this element present, the processing MUST fail		is returned with this element present, the processing MUST fail
	unless the PEP can perform the required action. A set of Plasma		unless the PEP can perform the required action. A set of Plasma
	specific obligations are found in Section 10.2. [anchor23]		specific obligations are found in Section 10.2. [anchor23]
	skipping to change at page 23, line 52 ¶		skipping to change at page 23, line 52 ¶
	for fewer round trips in later conversations. An example of a		for fewer round trips in later conversations. An example of a
	request token can be found in Appendix B.		request token can be found in Appendix B.
	The role token request, as with all requests, uses the eps:		The role token request, as with all requests, uses the eps:
	PlasmaRequest XML structure. The eps:Authentication MAY be included		PlasmaRequest XML structure. The eps:Authentication MAY be included
	on the first message and MUST be included on subsequent		on the first message and MUST be included on subsequent
	authentication round trips.		authentication round trips.
	A role token request by a client MUST include the GetRoleTokens		A role token request by a client MUST include the GetRoleTokens
	Plasma action request as an attribute of the xacml:Request element.		Plasma action request as an attribute of the xacml:Request element.
	Details on the action can be found in section Section 12.1. When		Details on the action can be found in section Section 14.1. When
	role tokens are requested, no additional data needs to be supplied by		role tokens are requested, no additional data needs to be supplied by
	the requester.		the requester.
	An example of a message requesting the set of policy information is:		An example of a message requesting the set of policy information is:
	<esp:PlasmaRequest>		<esp:PlasmaRequest>
	<eps:Authentication>...</eps:Authentication>		<eps:Authentication>...</eps:Authentication>
	<xacml:Request>		<xacml:Request>
	<xacml:Attributes Category="...:action">		<xacml:Attributes Category="...:action">
	<xacml:Attribute AttributeId="urn:plasma:action-id">		<xacml:Attribute AttributeId="urn:plasma:action-id">
	skipping to change at page 25, line 5 ¶		skipping to change at page 25, line 5 ¶
	reached. When this decision is reached, the server SHOULD return		reached. When this decision is reached, the server SHOULD return
	a list of additional attributes to be returned and SHOULD return		a list of additional attributes to be returned and SHOULD return
	the list of role tokens that have been granted based on the		the list of role tokens that have been granted based on the
	attributes received to that point.		attributes received to that point.
	NotApplicable is returned if the Plasma server does not have the		NotApplicable is returned if the Plasma server does not have the
	capability to issue role tokens.		capability to issue role tokens.
	An example of a response returning the set of policy information is:		An example of a response returning the set of policy information is:
	<eps:PlasmaResponse>		<eps:PlasmaResponse>
	<xacml:Response>		<xacml:Response>
	<xacml:Result>		<xacml:Result>
	<xacml:Decision>Permit</xacml:Decision>		<xacml:Decision>Permit</xacml:Decision>
	</xacml:Result>		</xacml:Result>
	</xacml:Response>		</xacml:Response>
	<eps:PlasmaTokens>		<eps:PlasmaReturnToken xsi:type="RoleToken">
	<eps:PlasmaToken>		<eps:Name>Role Display Name</eps:Name>
	<eps:PolicyList>		<eps:PDP>PDP Url names</eps:PDP>
	<eps:Policy>		<eps:PolicyList>
	Details of a policy		<eps:Policy>
	</eps:Policy>		Details of a policy
	... More policies ...		</eps:Policy>
	<wst:RequestSecurityTokenResponse>		... More policies ...
	<wst:TokenType>urn:...:plasma:roleToken</wst:TokenType>		</eps:PolicyList>
	<wst:RequestedSecurityToken>...</wst:RequestedSecurityToken>		<wst:RequestSecurityTokenResponse>
	</wst:RequestSecurityTokenResponse>		<wst:TokenType>urn:...:plasma:roleToken</wst:TokenType>
	</eps:PolicyList>		<wst:RequestedSecurityToken>...</wst:RequestedSecurityToken>
	</eps:PlasmaToken>		</wst:RequestSecurityTokenResponse>
	</eps:PlasmaTokens>		</eps:PlasmaReturnToken>
	</eps:PlasmaResponse>		... More Role Tokens ...
			</eps:PlasmaResponse>
	In this example, the Email Policy Service is returning three
	different policies that can be used along with a security token and a
	key to be used with the token when sending an email.
	7.2.1. RoleToken XML element		7.2.1. RoleToken XML element
	The eps:PlasmaTokens element is used to return one or more tokens to		The eps:PlasmaReturnToken element is used to return a role token to
	the client. Each token returned will contain one or more policies		the client. Multiple role tokens can be returned by using multiple
	that can be asserted with the token and the token itself.		eps:PlasmaReturnToken elements. Each role token returned contains
	Additionally the name of a Plasma server to be used with the token		one or more policies that can be asserted, the role token, and
	can be included as well as cryptographic information to be used with		optionally one or more set of obligations or advice that need to be
	the token.		observed when creating messages. Additionally the name of a Plasma
			server to be used with the token can be included as well as
			cryptographic information to be used with the token.
	The schema used for the PlasmaTokens element is:		The schema used for the PlasmaTokens element is:
	<xs:element name="RoleToken" type="eps:RoleTokenType"/>		<xs:complexType name="RoleToken">
	<xs:complexType name="RoleTokenType">
	<xs:complexContent>		<xs:complexContent>
	<xs:extension base="eps:PlasmaReturnTokenType">		<xs:extension base="eps:PlasmaReturnTokenType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Name" type="xs:string"/>		<xs:element name="Name" type="xs:string"/>
	<xs:element name="PDP" type="xs:anyURI" maxOccurs="unbounded"/>		<xs:element name="PDP" type="xs:anyURI" maxOccurs="unbounded"/>
	<xs:choice>		<xs:choice>
	<xs:element name="PolicyList">		<xs:element name="PolicyList">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element name="Policy" type="eps:PolicyType" maxOccurs="unbounded"/>		<xs:element name="Policy" type="eps:PolicyType" maxOccurs="unbounded"/>
	skipping to change at page 26, line 32 ¶		skipping to change at page 26, line 43 ¶
	<xs:complexContent>		<xs:complexContent>
	<xs:extension base="xs:anyType">		<xs:extension base="xs:anyType">
	<xs:attribute name="optionsType" type="xs:anyURI" use="required"/>		<xs:attribute name="optionsType" type="xs:anyURI" use="required"/>
	</xs:extension>		</xs:extension>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>		<xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>
	</xs:complexType>		</xs:complexType>
	<xs:element name="Label" type="eps:LabelType"/>
	<xs:complexType name="LabelType">
	<xs:sequence>
	<xs:choice maxOccurs="unbounded">
	<xs:element ref="eps:Label"/>
	<xs:element ref="eps:Leaf"/>
	</xs:choice>
	</xs:sequence>
	<xs:attribute name="CombiningRule" type="eps:CombiningRuleType" use="required"/>
	</xs:complexType>
	<xs:simpleType name="CombiningRuleType">
	<xs:restriction base="xs:string">
	<xs:enumeration value="and"/>
	<xs:enumeration value="or"/>
	<xs:enumeration value="except"/>
	</xs:restriction>
	</xs:simpleType>
	<xs:element name="Leaf" type="eps:LeafType"/>
	<xs:complexType name="LeafType">
	<xs:sequence>
	<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	<xs:attribute name="Label" type="xs:string" use="required"/>
	</xs:complexType>
	The eps:PlasmaTokens field will contain one or more eps:PlasmaToken		The eps:RoleToken element contains the following items:
	elements.
	The eps:PlasmaToken element contains the following items:		Name This element returns a descriptive name of the role as a whole.
			The string returned SHOULD be selected based on the language
			attribute on the request message. The stri8ng is suitable for
			display to the user and should be indicative of the scope of the
			role. Examples of role descriptive strings would be "Company
			President", "Senior Executive", "Project X Electrical Engineer".
	PDP is an optional element. If the element is present, it provides		PDP The element provides one or more URLs to be used for contacting
	one or more URLs to be used for containing a Plasma server for the		a Plasma server for the purpose of sending a message. This
	purpose of sending a message. This element allows for the use of		element allows for the use of different Plasma servers for issuing
	different Plasma servers for issuing role tokens and message		role tokens and message tokens. No ranking of the servers is
	tokens. No ranking of the servers is implied by the order of the		implied by the order of the URLs returned.
	URLs returned.
	PolicyList contains the description of one or more policies that can		PolicyList contains the description of one or more policies that can
	be asserted using the issued token. Any of the policies contained		be asserted using the issued role token. Any of the policies
	in the list may be combined together using the policy logic in		contained in the list may be combined together using the policy
	constructing a label during the send message process.		logic in constructing a label during the send message process.
	Label contains a single specific label. This element is returned as		Label contains a single specific label. This element is returned as
	part of a read message token to allow for replies to be formulated		part of a read message token to allow for replies to be formulated
	by an entity that cannot generally originate a message using the		by an entity that cannot generally originate a message using the
	policy.		policy.
	wst:RequestSecurityTokenResponse contains the actual token itself.		wst:RequestSecurityTokenResponse contains the actual token itself.
	The eps:PolicyType type is used to represent the elements of a policy		The eps:PolicyType type is used to represent the elements of a policy
	to the client. The elements in this type are:		to the client. The elements in this type are:
	Name contains a display string that represents the policy. This		Name contains a display string that represents the policy. This
	element is localized in response to the TBD attribute in the TBD		element is localized in response to the TBD attribute in the TBD
	field.		field.
	Identifier contains a "unique" identifier for the policy. This is		PolicyId This attribute contains a "unique" identifier for the
	the value that identifies the policy to the software. The type		policy. This is the value that identifies the policy to the
	for the value is defined as a string and is expected to be either		software. The type for the value is defined as a URI.
	a URN, and Object Identifier or some equally unique identifier.
	Options allows for a set of options to be specified for the policy.		Options This element is used to inform the client what the set of
	The set of options is dependent on the policy and only those		options that need to be filled in as part of asserting the policy.
	clients which have pre-knowledge of a policy are expected to be		If the client software does not understand how to set the options
	able to deal with them. The options can range from a simple		for the supplied type, then the client software MUST NOT allow the
	yes/no selection to a list of strings. An example of using		user to assert the policy. The option structure is identified by
	options is provided by the basic policies defined in [TBD] where a		the URI in the optionsType attribute. This document defines one
	set of RFC 822 names is provided.[anchor27]		option structure in section Section 7.2.2. This option structure
			is used in the basic policies defined in [PlasmaBasicPolicy].
	When building the wst:RequestSecurityTokenResponse element, the		When building the wst:RequestSecurityTokenResponse element, the
	following should be noted:		following should be noted:
	A wst:RequestedSecurityToken element containing the security token		A wst:RequestedSecurityToken element containing the security token
	MUST be included. The format of the security token is not		MUST be included. The format of the security token is not
	specified and is implementation specific, it is not expected		specified and is implementation specific, it is not expected
	that[anchor28] . Examples of items that could be used as security		that[anchor27] . Examples of items that could be used as security
	tokens are SAML statements, encrypted record numbers in a server		tokens are SAML statements, encrypted record numbers in a server
	database.		database.
	A wst:Lifetime giving the life time of the token SHOULD be		A wst:Lifetime giving the life time of the token SHOULD be
	included. It is not expected that this should be determinable		included. It is not expected that this should be determinable
	from the token itself and thus must be independently provided.		from the token itself and thus must be independently provided.
	There is no guarantee that the token will be good during the		There is no guarantee that the token will be good during the
	lifetime as it make get revoked[anchor29] due to changes in		lifetime as it make get revoked[anchor28] due to changes in
	credentials, however the client is permitted to act as if it were.		credentials, however the client is permitted to act as if it were.
	The token provided may be used for duration. If this element is		The token provided may be used for duration. If this element is
	absent, it should be assumed that the token is either a one time		absent, it should be assumed that the token is either a one time
	token or of limited duration.		token or of limited duration.
	Talk about cryptographic information		Talk about cryptographic information
			7.2.2. Email Address List Options
			Some policies are designed to be restricted to a set of explicitly
			named people by the sender of the message. This policy is used for
			the set of basic policies defined in [PlasmaBasicPolicy]. In these
			cases the creator of the message specifies a set of recipients by
			using email address names without any decoration.
			The Email Address List Option is identified by the uri
			"urn:ietf:plasma:options:emailAddrs". The type associated with the
			structure is a string. The string contains a space separated set of
			email addresses.
			All Plasma clients and servers MUST be able to create, parse and use
			the Email Address List Option for any policy.
			As of the release of this document, Plasma clients and servers are
			not expected to understand any other options.
	8. Sending An Email		8. Sending An Email
	After having obtained a role token from a Plasma server, the client		After having obtained a role token from a Plasma server, the client
	can then prepare to send an Email by requesting a message token from		can then prepare to send an Email by requesting a message token from
	the Plasma server. As part of the preparatory process, the client		the Plasma server. As part of the preparatory process, the client
	will construct the label to be applied to the Email from the set of		will construct the label to be applied to the Email from the set of
	policies that it can assert, determine the optional elements for		policies that it can assert, determine the optional elements for
	those policies which have options, generate the random key encryption		those policies which have options, generate the random key encryption
	key and possible create the key recipient structures for the email.		key and possible create the key recipient structures for the email.
	Although this section is written in terms of a CMS Encrypted message,		Although this section is written in terms of a CMS Encrypted message,
	there is nothing to prevent the specification of different formats		there is nothing to prevent the specification of different formats
	and still use this same basic protocol. An example of a request		and still use this same basic protocol. An example of a request
	token exchange can be found in Appendix D.		token exchange can be found in Appendix D.
	8.1. Send Message Request		8.1. Send Message Request
	The send message request is built using the eps:PlasmaRequest XML		The send message request is built using the eps:PlasmaRequest XML
	structure. When building the request, the following applies:		structure. When building the request, the following applies:
	o The eps:Authentication element MAY be included in the initial		o The eps:Authentication element SHOULD be included in the initial
	message. The authorization is supplied by the role token which is		message. The authorization is supplied by the role token returned
	included in the data structure, however authentication may be		above, however authentication may be required as well. The
	required as well. The authentication data is placed here.		authentication data is placed here.
	o The xacml:Request element MUST be included in the initial message.		o The xacml:Request element MUST be included in the initial message.
	o The client MUST include an action attribute. This document		o The client MUST include an action attribute. This document
	defines the action attribute to be used for purpose:		defines the GetSendCMSTOken action attribute for this purpose.
	Category = "urn:oasis:name:tc:xacml:3.0:attribute-category:action"
	AttributeId="urn:ietf:plasma:action-id"
	Attribute Value= GetSendCMSToken
	o The client MUST include a data attribute. This attribute contains		o The client MUST include a data attribute. This attribute contains
	the information that is used to build the CMS Message token to be		the information that is used to build the CMS Message token to be
	returned. There MAY be more than one data attribute, but this		returned. There MAY be more than one data attribute, but this
	will not be a normal case. More details on this attribute are in		will not be a normal case. More details on this attribute are in
	Section 8.1.1.		Section 8.1.1.
	o If the client is using the XML Digital Signature element in this		o If the client is using the XML Digital Signature element in this
	message, then the client MUST include the cryptographic channel		message, then the client MUST include the cryptographic channel
	binding token (xref target="ChannelBind"/>) in the set of XACML		binding token (Section 10.1.1) in the set of XACML attributes.
	attributes.
	An example of a message returning the set of policy information is:		A message requesting that a CMS message token be created looks like
			this:
	<eps:PlasmaRequest>		<eps:PlasmaRequest>
	<eps:Authentication>		<eps:Authentication>
	<eps:WS_Token>		<eps:WS_Token>
	Role Token goes here		Role Token goes here
	</eps:WS_Token>		</eps:WS_Token>
	<xacml:Request>
	<xacml:Attributes Category="...:action">
	<xacml:Attribute AttributeId="urn:plasma:action-id">
	<xacml:AttributeValue>
	GetSendCMSToken
	</xacml:AttributeValue>
	</xacml:Attribute>
	</xacml:Attributes>
	<xacml:Attributes Category="...:data">
	<xcaml:Attribute AttributeId="urn:plasma:data-id">
	<xacml:AttributeValue>
	Label and keys
	</xacml:AttributeValue>
	</xcaml:Attribute>
	</xacml:Attributes>
	</xacml:Request>
	</eps:Authentication>		</eps:Authentication>
			<xacml:Request>
			<xacml:Attributes Category="...:action">
			<xacml:Attribute AttributeId="urn:plasma:action-id">
			<xacml:AttributeValue>
			GetSendCMSToken
			</xacml:AttributeValue>
			</xacml:Attribute>
			</xacml:Attributes>
			<xacml:Attributes Category="...:data">
			<xcaml:Attribute AttributeId="urn:plasma:data-id">
			<xacml:AttributeValue>
			<eps:GetCMSToken>
			<eps:Label>
			... Label Tree for message ...
			</eps:Label>
			<eps:Hash>
			... Hash algorithm and hash of encrypted content ...
			</eps:Hash>
			<eps:CEK>
			... Content Encryption Key ...
			</eps:CEK>
			</eps:GetCMSToken>
			</xacml:AttributeValue>
			</xcaml:Attribute>
			</xacml:Attributes>
			</xacml:Request>
	</eps:PlasmaRequest>		</eps:PlasmaRequest>
	8.1.1. CMS Message Token Data Structure		8.1.1. CMS Message Token Data Structure
	The message token data structure is used as an attribute to carry the		The message token data structure is used as an attribute to carry the
	necessary information to issue a CMS message token. The schema that		necessary information to issue a CMS message token. The schema that
	describes the structure is:		describes the structure is:
	<xs:element name="MessageTokenRequest" type="eps:MessageTokenRequestType"/>		<xs:element name="GetCMSToken" type="eps:CMSTokenRequestType"/>
	<xs:complexType name="MessageTokenRequestType">		<xs:complexType name="CMSTokenRequestType">
	<xs:sequence>		<xs:sequence>
	<xs:choice>		<xs:choice>
	<xs:element ref="eps:Label"/>		<xs:element ref="eps:Label"/>
	<xs:element ref="eps:Leaf"/>		<xs:element ref="eps:Leaf"/>
	</xs:choice>		</xs:choice>
	<xs:element name="Hash">		<xs:element name="Hash">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element ref="ds2:DigestMethod"/>		<xs:element ref="ds2:DigestMethod"/>
	<xs:element ref="ds2:DigestValue"/>		<xs:element ref="ds2:DigestValue"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:element name="Recipient" type="eps:RecipientInfoType" minOccurs="0" maxOccurs="unbounded"/>		<xs:element name="Recipient" type="eps:RecipientInfoType" minOccurs="0" maxOccurs="unbounded"/>
	<xs:element name="KEK" minOccurs="0">		<xs:element name="CEK" type="xs:hexBinary" minOccurs="0"/>
	<xs:complexType>
	<xs:sequence>
	<xs:element name="Identifer" type="xs:hexBinary"/>
	<xs:element name="Value" type="xs:hexBinary"/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:element name="RecipientInfo" type="eps:RecipientInfoType"/>		<xs:element name="RecipientInfo" type="eps:RecipientInfoType"/>
	<xs:complexType name="RecipientInfoType">		<xs:complexType name="RecipientInfoType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Subject" maxOccurs="unbounded">		<xs:element name="Subject" maxOccurs="unbounded">
	<xs:complexType>		<xs:complexType>
	<xs:simpleContent>		<xs:simpleContent>
	<xs:extension base="xs:anySimpleType">		<xs:extension base="xs:anySimpleType">
	<xs:attribute name="type" type="xs:string" use="required"/>		<xs:attribute name="type" type="xs:string" use="required"/>
	</xs:extension>		</xs:extension>
	</xs:simpleContent>		</xs:simpleContent>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:element name="LockBox" type="xs:hexBinary"/>		<xs:element name="LockBox" type="xs:base64Binary"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	When used in an xacml:Attribute, the structure is identified by:		When used in an xacml:Attribute, the structure is identified by:
	Category = "urn:oasis:name:tc:xacml:3.0:attribute-category:data"		Category = "urn:oasis:name:tc:xacml:3.0:attribute-category:data"
	AttributeId = "urn:ietf:plasma:data-id"		AttributeId = "urn:ietf:plasma:data-id"
	DataType = "http://www.w3.org/2001/XMLSchema#anyType"		DataType = "http://www.w3.org/2001/XMLSchema#anyType"
	The elements of the structure are used as:		The elements of the structure are used as:
	RoleToken contains the previously issued role token which provides		Leaf
	the authorization to use the policies in the label.		This element contains a the policy to be applied to the message
			when a single policy is used.
	Label contains the label to be applied to the message.		Label
			This element contains the policy to be applied to the message when
			a combination of policies is to be applied.
	Recipients is an optional element that contains one or more		Hash
	recipient info structures.		This element contains the hash of the encrypted content of the
			message that the policy is being applied to. The algorithm used
			to compute the hash is contained in the DigestMethod element and
			the value is contained in the DigestValue element.
	KEK is an optional element that contains the KEK to decrypt the CMS		Recipients
	lock box.		This optional element contains a recipient info structure for a
			message recipient. This element may be repeated when more than
			one lock box is pre-computed for recipients by the message sender.
			This element is used in those cases where the sender does not want
			to share the content encryption key with the Plasma server and the
			sender has the ability to retrieve the necessary keys for all of
			the recipients. If the #### obligation was returned for the role
			token, then a recipient info lock box MUST be created for the
			Plasma server and the CEK element MUST absent.
	One or both of KEK and Recipients MUST be present.		CEK
			This optional element contains the content encryption key (CEK) to
			decrypt the message.
			One or both of CEK and Recipients elements MUST be present.
	The elements of the RecipientInfoType structure are:		The elements of the RecipientInfoType structure are:
	Subject contains a subject identifier. Since a CMS recipient info		Subject
	structure does not contain a great deal of information about the		This element contains a subject identifier. Since a CMS recipient
	recipient, this element contains a string which can be used to		info structure does not contain a great deal of information about
			the recipient, this element contains a string which can be used to
	identify the subject. This will normally be an RFC 822 name.		identify the subject. This will normally be an RFC 822 name.
	Multiple subject names can be provided for a single lock box.		Multiple subject names can be provided for a single lock box.
	This allows for the use a KEK value that is shared among the set
	of recipients but not the Plasma server.
	LockBox contains a hex encoded CMS Recipient Info structure. If the		LockBox contains a base64 encoded CMS Recipient Info structure. If
	recipient info structure is placed here, it MUST NOT be placed in		the recipient info structure is placed here, it MUST NOT be placed
	the CMS EnvelopedData structure as well.		in the CMS EnvelopedData structure as well.
			8.1.2. XML Label Structure
			A client is allowed to build a complex label to be sent to the Plasma
			server for evaluation. While there are some cases that a simple
			single policy is applied to a message, it is expected that many, if
			not most, messages will have more than one policy applied to it with
			logical statements connected those policies.
			The schema for specifying a label is:
			<xs:element name="Label" type="eps:LabelType"/>
			<xs:complexType name="LabelType">
			<xs:sequence>
			<xs:choice maxOccurs="unbounded">
			<xs:element ref="eps:Label"/>
			<xs:element ref="eps:Leaf"/>
			</xs:choice>
			</xs:sequence>
			<xs:attribute name="CombiningRule" type="eps:CombiningRuleType" use="required"/>
			</xs:complexType>
			<xs:simpleType name="CombiningRuleType">
			<xs:restriction base="xs:string">
			<xs:enumeration value="and"/>
			<xs:enumeration value="or"/>
			<xs:enumeration value="except"/>
			</xs:restriction>
			</xs:simpleType>
			<xs:element name="Leaf" type="eps:LeafType"/>
			<xs:complexType name="LeafType">
			<xs:sequence>
			<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>
			</xs:complexType>
			The Label and the Leaf elements are used when specifying a policy for
			a message depending on whether multiple policies or a single policy
			is to be evaluated.
			The Leaf element is used to specify a single policy to the server
			along with any options that are defined for that policy. The Leaf
			element contains:
			PolicyId
			Is an attribute that contains the URI which identifies a specific
			policy to be evaluated.
			The content of the Leaf element can be any XML element. The
			content is to be a set of options for the policy. The schema
			applied to the content is based on the policy selected.
			The Label element is used to specify a logical set of policies to be
			applied to the message. This element allows one to specify multiple
			policies along with a logic operation to combine them togeither.
			Label
			This element allows for a logical set of policies to be
			recursively evaluated. This element can occur zero or more times.
			Leaf
			This element allows for a single policy and any options for the
			policy to be specified. This element can occur zero or more
			times.
			CombiningRule
			This attribute specifies the operation to be used in combining the
			elements of the tree together. This attribute can contain either
			a string or a URI. If it is a string it MUST be one of the
			strings defined in this document. Examples of URIs that could be
			used can be found in Section XX of [XACML]. Servers MUST be able
			to evaluate the set of logical operations defined here, but other
			combining rules can be implemented as well. The set of string
			values defined in this document are:
			and All policies referenced by this element MUST evaluate to
			accept.
			or At least one policy referenced by this element MUST evaluate to
			accept.
			except When this combining rule is used, there MUST be exactly
			two policy elements. The rule evaluates to accept if and only
			if the first element evaluates to accept and the second does
			not evaluate to accept.
			TODO: Correct the following text to make sense in the XML space
			rather than in the ASN.1 space
			8.1.2.1. Label Extensibility
			The ASN.1 type OneLabel has been explicitly defined to allow for
			later extensibility. When a new element is added, it will be added
			with at the end of the choice with a different tag value. ASN.1
			decoders need to following the current recommendations on dealing
			with extensibility. This means that when the decoder finds a new
			choice in this structure that is not part of the current syntax, the
			element should be treated as an unknown blob and returned to the
			caller as an unrecognized blob. This allows for the calling code to
			make the decision on how the unknown element is treated.
			However the extensibility is not handled the same in all cases. Each
			of the four different cases is outlined below.
			8.1.2.1.1. Sender Composing
			The set of policies that can be used by the sender in applying a
			label is usually given as a list of policies, however under some
			circumstances the sender may be handed structured policies either for
			application or for checking that some policies can be used together.
			If structured policies are provided to the sender, it will not matter
			to the sender that they cannot evaluate the policy unless the details
			are to be shown to the sending user. Following the current ASN.1
			rules which allow for the decoding and then re-encoding of a type
			which contains unknown nodes allows the sending agent the most
			flexibility.
			The protocol used to give the policy information to the sending
			client may not use the ASN.1 structure provided here or configuration
			purposes but would generally be expected to provide for a different
			data format.
			8.1.2.1.2. Sender to Email Policy Service
			In the sending agent to Email Policy Service protocol (defined
			external to this document) the ASN.1 type OneLabel may or may not be
			used directly. If it is used, then the Email Policy Server is
			expected to reject the label if it contains elements which it does
			not understand. The general expectation is that the Email Policy
			Service that the sender is communicating with is going to be the same
			one as is later enforcing the policy. It makes no sense for this
			server to accept a policy that it would later be unable to enforce.
			The protocol should make provisions for the return of this as an
			explicit error code. Having the ASN.1 decoded allows for the
			communication of the exact tag that is causing the problem. Under
			most policies, the evaluation of sender policy would be expected to
			be different than laid out in the next session. As a general rule,
			the sender should be permitted to assert all of the leaf policies for
			the purpose of sending.
			8.1.2.1.3. Recipient to Email Policy Service
			The Email Policy Service which recipient communicates way is normally
			the same server as the sender communicated with. However the server
			can be a different server, or the server may have been downgraded in
			the mean time. In this case the policy evaluation need to be
			conservative. There are two different ways of doing this evaluation.
			The first option is to say that if an unknown node is found, then the
			policy evaluation results in "Deny" for all cases. The second option
			is to try and evaluation the policy, but to do so in a conservative
			manner. In this section we use the same terms as XACML [XACML] uses
			in section 7.2.1. If the second option is chosen then the following
			rules are used:
			uriLeaf results in "Permit", "Deny", "Not Applicable" or
			"Indeterminate". "Not Applicable" results if the policy is
			unknown. "Indeterminate" results if the policy cannot be
			evaluated.
			oidLeaf results in "Permit", "Deny", "Not Applicable" or
			"Indeterminate". "Not Applicable" results if the policy is
			unknown. "Indeterminate" results if the policy cannot be
			evaluated.
			andLabels results in "Deny" if any input node is "Deny" or "Not
			Applicable". It results in "Permit" if all of the input nodes are
			"Permit". Otherwise it results in "Indeterminate".
			orLabels results in "Permit" if any input node is "Permit". It
			results in "Deny" if all nodes are either "Deny" or "Not
			Applicable". Otherwise it results in "Indeterminate".
			exclude results in "Deny" if the first element is "Deny" or if the
			second input is "Permit". It results in "Permit" if the first
			input is "Permit" and the second is "Deny". It results in "Not
			Applicable" if either element is "Not Applicable". Otherwise it
			results in "Indeterminate".
			If the final node results in "Permit", then access is granted. If
			the final result is either "Deny" or "Not Applicable" then access is
			denied. If the final result is "Indeterminate", then access is
			denied, however if the protocol permits, then the result can be "Not
			Applicable" and the attributes needed to do the policy evaluation can
			be requested and policy evaluation may be re-attempted.
			Any future element that is added to the choice needs to define a
			similar rule to the set of rules above.
			8.1.2.1.4. Recipient User Agent Display
			Recipient user agents may want to display the policy to the user.
			This policy may be communicated from the Email Policy Service to the
			recipient using the OneLabel ASN.1 structure or using a different
			type. The label has been successfully (or unsuccessfully) validated
			so access has been granted (or denied) to the message. At this point
			we are only talking about a user interface issue. The recipient user
			agent should make some type of provision for indicating that an
			operation was placed in that location of the tree, but the agent is
			not aware of what the operation is.
	8.2. Send Message Response		8.2. Send Message Response
	In response to a send message request, the Plasma server returns a		In response to a send message request, the Plasma server returns a
	send message response message. The response messages uses the eps:		send message response message. The response messages uses the eps:
	PlasmaResponse XML structure. When the response message is created,		PlasmaResponse XML structure. When the response message is created,
	the following should be noted:		the following should be noted:
	o The xacml:Decisions is always included in the response. If the		o The xacml:Decisions is always included in the response. If the
	'Permit' value is returned then the eps:CMSToken element MUST be		'Permit' value is returned then the eps:CMSToken element MUST be
	present.		present.
	o The eps:CMSToken element is included in a permit message. It		o The PlasmaReturnToken element with a eps:CMSToken content is
	contains value of the keyatt-eps-kek attribute defined in		included with a permit response. The CMSToken contains one or
	[EPS-CMS].		more CMS RecipientInfo objects to be included in the message sent.
	An example of a message returning the set of policy information is:		An example of a message returning the set of policy information is:
	<eps:PlasmaResponse>		<eps:PlasmaResponse>
	<xacml:Response>		<xacml:Response>
	<xacml:Result>		<xacml:Result>
	<xacml:Decision>Permit</xacml:Decision>		<xacml:Decision>Permit</xacml:Decision>
	</xacml:Result>		</xacml:Result>
	</xacml:Response>		</xacml:Response>
	<eps:CMSToken>234e34d3</eps:CMSToken>		<eps:PlasmaReturnToken xsi:"eps:CMSTokenResponseType">
			<eps:RecipientInfo>234e34d3</eps:RecipientInfo>
			</eps:PlasmaReturnToken>
	</eps:PlasmaResponse>		</eps:PlasmaResponse>
	The schema use for returning a CMS token is:		The schema use for returning a CMS token is:
	<xs:element name="CMSToken" type="eps:CMSTokenResponseType"/>		<xs:element name="CMSToken" type="eps:CMSTokenResponseType"/>
	<xs:complexType name="CMSTokenResponseType">		<xs:complexType name="CMSTokenResponseType">
	<xs:complexContent>		<xs:complexContent>
	<xs:extension base="eps:PlasmaReturnTokenType"/>		<xs:extension base="eps:PlasmaReturnTokenType">
			<xs:sequence>
			<xs:element name="RecipientInfo" maxOccurs="unbounded">
			<xs:complexType>
			<xs:simpleContent>
			<xs:extension base="xs:base64Binary">
			<xs:attribute name="CMSType" type="xs:string"/>
			</xs:extension>
			</xs:simpleContent>
			</xs:complexType>
			</xs:element>
			</xs:sequence>
			</xs:extension>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	This schema extends the Plasma response token type and restricts the		This schema fragment extends the Plasma response token type and
	content to a hex encoded binary value. The hex encoded binary value		allows for the return of one or more base64 encoded RecipientInfo
	is a the CMS SignedData structure that is the Plasma Key Attribute		structures. The Plasma server can return recipient info information
	value to be encoded in the CMS KEKRecipientInfo structure (for		for any recipient that it pre-authorizes to receive the message (see
	details see [EPS-CMS]).		Section ### of [Plasma] for examples of when this would occur).
			Additionally the Plasma server can return a KEKRecipientInfo
			structure with the Plasma Other Key attribute. (For details see
			[EPS-CMS].) In some extremely rare cases where the Plasma server can
			pre-authorize the entire set of recipients , the KEKRecipientInfo
			structure with the Plasma Other Key Attribute may not be included in
			the returned set of recipients. The recipient info structure for the
			plasma server SHOULD be placed last in the list of recipients infos.
			The CMSTokenResponse type has the following:
			RecipientInfo
			This element contains the ASN.1 encoding for a CMS RecipientInfo
			structure to be placed in the final message.
			CMSType
			This attribute of the RecipientInfo structure is an optional text
			value that identifies the type of recipient info structure
			returned. NOTE: This attribute is currently optional and is
			likely to disappear if I do not find it useful.
	9. Decoding A Message		9. Decoding A Message
	When the receiving agent is ready to decrypt the email, it identifies		When the receiving agent is ready to decrypt the email, it identifies
	that there is a KEKRecipientInfo object which contains a key		that there is a KEKRecipientInfo object which contains a key
	attribute identified by id-keyatt-eps-token. It validates the		attribute identified by id-keyatt-eps-token. It validates the
	signature, determines that communicating with the Email Policy		signature, determines that communicating with the Plasma Service is
	Service is within local policy, and then sends a request to the		within local policy, and then sends a request to the service to
	service to obtain the encryption key for the message.		obtain the decryption key for the message.
	In some cases the recipient of a message is not authorized to use the		In some cases the recipient of a message is not authorized to use the
	same set of labels for sending a message. For this purpose a token		same set of labels for sending a message. For this purpose a token
	can be returned in the message along with the key so that recipient		can be returned in the message along with the key so that recipient
	of the can reply to the message using the same set of security		of the can reply to the message using the same set of security
	labels.		labels.
	9.1. Requesting Message Key		9.1. Requesting Message Key
	The client sends a request to the Plasma server that is identified in		The client sends a request to the Plasma server that is identified in
	the token. For the CMS base tokens, the address of the Plasma server		the token. For the CMS base tokens, the address of the Plasma server
	to use is defined in [EPS-CMS] this is located in the aa-eps-url		to use is defined in [EPS-CMS] this is located in the aa-eps-url
	attribute.		attribute.
	The request uses the eps:PlasmaRequest XML structure. When building		The request uses the eps:PlasmaRequest XML structure. When building
	the request, the following should be noted:		the request, the following should be noted:
	o The xacml:Request MUST be present in the first message of the		o The xacml:Request MUST be present in the first message of the
	exchange.		exchange.
	o The action used to denote that a CMS token should be decrypted is:		o The action used to denote that a CMS token should be decrypted is
			"ParseCMSToken".
	Category="urn:oasis:names:tc:xaml:3.0:attribute-category:action"
	AttributeId="urn:ietf:plasma:action-id"
	Attribute Value: ParseCMSToken
	o The CMS token to be cracked is identified by:[anchor30]
	Category="urn:oasis:names:tc:xacml:3.0:attribute-cateogry:data"		o The CMS token to be cracked is identified by "CMSToken"
	AttributeId="urn:ietf:plasma:data-id"
	Attribute Value: CMSToken
	o In the event that a reply to role token is wanted as well, then		o In the event that a reply to role token is wanted as well, then
	that is supplied as a separate action:		that is supplied as a separate action.[anchor33] In this case the
			action is "GetReplyToken".
	Category="urn:oasis:names:tc:xaml:3.0:attribute-category:action"
	AttributeId="urn:ietf:plasma:action-id"
	Attribute Value: GetReplyToken
	o If the client is using the XML Digital Signature element in this		o If the client is using the XML Digital Signature element in this
	message, then the client MUST include the cryptographic channel		message, then the client MUST include the cryptographic channel
	binding token (xref target="ChannelBind"/>) in the set of XACML		binding token (Section 10.1.1) in the set of XACML attributes.
	attributes.
	An example of a message returning the set of policy information is:		An example of a message returning the set of policy information is:
	<eps:PlasmaRequest>		<eps:PlasmaRequest>
	<eps:Authentication>...</eps:Authentication>		<eps:Authentication>...</eps:Authentication>
	<xacml:Request>		<xacml:Request>
	<xacml:Attributes Category="...:action">		<xacml:Attributes Category="...:action">
	<xacml:Attribute AttributeId="..:action-id">		<xacml:Attribute AttributeId="..:action-id">
	<xacml:AttributeValue>ParseCMSToken</xacml:AttributeValue>		<xacml:AttributeValue>ParseCMSToken</xacml:AttributeValue>
	</xacml:Attribute>		</xacml:Attribute>
	</xacml:Attributes>		</xacml:Attributes>
	<xacml:Attribute Category="...:data">		<xacml:Attribute Category="...:data">
	<xacml:Attribute AttreibuteId="..:data-id">		<xacml:Attribute AttreibuteId="..:data:CMSToken">
	<xacml:AttributeValue>		<xacml:AttributeValue>
	Hex encoded CMS Token Value		Base64 encoded CMS Token Value
	</xacml:AttributeValue>		</xacml:AttributeValue>
	</xacml:Attribute>		</xacml:Attribute>
	</xacml:Attribute>		</xacml:Attribute>
	</xacml:Request>		</xacml:Request>
	</eps:PlasmaRequest>		</eps:PlasmaRequest>
	9.2. Requesting Message Key Response		9.2. Requesting Message Key Response
	In response to a message key request, the Plasma server returns a		In response to a message key request, the Plasma server returns a
	decrypted key in the message key response. The response message uses		decrypted key in the message key response. The response message uses
	skipping to change at page 36, line 16 ¶		skipping to change at page 41, line 4 ¶
	<xacml:Response>		<xacml:Response>
	<xacml:Result>		<xacml:Result>
	<xacml:Decision>Permit</xacml:Decision>		<xacml:Decision>Permit</xacml:Decision>
	</xacml:Result>		</xacml:Result>
	</xacml:Response>		</xacml:Response>
	<eps:CMSKey>		<eps:CMSKey>
	<eps:DisplayString>Label TExt</eps:DisplayString>		<eps:DisplayString>Label TExt</eps:DisplayString>
	<eps:KEK>hex based KEK</eps:KEK>		<eps:KEK>hex based KEK</eps:KEK>
	</eps:CMSKey>		</eps:CMSKey>
	</eps:PlasmaResponse>		</eps:PlasmaResponse>
	The schema for returning the decrypted key is:		The schema for returning the decrypted key is:
	<xs:element name="CMSKey" type="eps:CMSKeyResponseType"/>		<xs:element name="CMSKey" type="eps:CMSKeyResponseType"/>
	<xs:complexType name="CMSKeyResponseType">		<xs:complexType name="CMSKeyResponseType">
	<xs:complexContent>		<xs:complexContent>
	<xs:extension base="eps:PlasmaReturnTokenType">		<xs:extension base="eps:PlasmaReturnTokenType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="DisplayString" type="xs:string"/>		<xs:element name="DisplayString" type="xs:string"/>
	<xs:choice>		<xs:choice>
	<xs:element name="KEK" type="xs:hexBinary"/>		<xs:element name="CEK" type="xs:hexBinary"/>
	<xs:element name="KEKIdentifier" type="xs:hexBinary"/>		<xs:element ref="eps:RecipientInfo"/>
	<xs:element ref="eps:RecipientInfo"/>		</xs:choice>
	</xs:choice>		<xs:element name="ResponseRoleToken" type="eps:RoleToken" minOccurs="0"/>
	<xs:element ref="eps:RoleToken" minOccurs="0"/>		<xs:element name="EncryptionRequestor" type="xs:string"/>
	<xs:element name="EncryptionRequestor" type="xs:string"/>		</xs:sequence>
	</xs:sequence>		</xs:extension>
	</xs:extension>		</xs:complexContent>
	</xs:complexContent>		</xs:complexType>
	</xs:complexType>
	This schema extends the Plasma response token type and restricts the		This schema extends the Plasma response token type and restricts the
	content to the listed elements. The values returned are:		content to the listed elements. The values returned are:
	DisplayString returns a localized display string for the policy(s)		DisplayString returns a localized display string for the policy(s)
	which were applied to the message. The lang attribute on the		which were applied to the message. The lang attribute on the
	request is used to determine which language to use for this		request is used to determine which language to use for this
	string.		string.
	KEK returns the base64 encoded key encryption key.		KEK returns the base64 encoded key encryption key.
	skipping to change at page 41, line 5 ¶		skipping to change at page 46, line 5 ¶
	The ObligationId attribute is		The ObligationId attribute is
	"urn:ietf:params:xml:plasma:obligation:encryption-required".		"urn:ietf:params:xml:plasma:obligation:encryption-required".
	An S/MIME Capabilities data value MUST be included containing the		An S/MIME Capabilities data value MUST be included containing the
	set of permitted encryption algorithms. The algorithms included		set of permitted encryption algorithms. The algorithms included
	MUST include a sufficient set of algorithms for the message to be		MUST include a sufficient set of algorithms for the message to be
	encrypted. An absolute minimum would be a content encryption		encrypted. An absolute minimum would be a content encryption
	algorithm and key encryption algorithm.		algorithm and key encryption algorithm.
	11. Security Considerations		11. Certificate Profiles
			We need to put in text to express the following items:
			DNS or IPAddr subject alt name to be present
			Have one of four EKUs
			Plasma Token EKU - Signals that it can sign and/or encrypt a
			plasma object
			Plasma Secure Session - Use for the TLS session
			Plasma CEK Transport - Used for transporting the CEK to the
			server in high security situations
			MUST NOT have the anyPolicy EKU set
			12. Message Transmission
			Plasma messages are sent over a TCP connection using port TBD1 on the
			server. The client first setups up TLS on the connection, then sends
			the UTF8 encoded XML message over the TLS connection as an atomic
			message. The XML MUST be encoded as UTF8, however the Byte Order
			Mark (BOM) is sent. The response comes back on the same connection.
			The client is responsible for closing the TLS session and the TCP
			connection when either no more messages are to be sent to the server
			or a final indeterminate state has been reached.
			If a Plasma server receives an XML request which is not well formed
			XML, the server if free to close the connection without first sending
			an error reply.
			The Plasma server SHOULD support TLS resumption [RFC5077].
			Plasma clients and server MUST support TLS 1.1 [RFC4346] and above.
			Implementations SHOULD NOT allow for the use of TLS 1.0 or SSL.
			13. Security Considerations
	To be supplied after we have a better idea of what the document looks		To be supplied after we have a better idea of what the document looks
	like.		like.
	12. IANA Considerations		14. IANA Considerations
	We define the following name spaces		We define the following name spaces
	New name space for the plasma documents urn:ietf:params:xml:ns:plasma		New name space for the plasma documents urn:ietf:params:xml:ns:plasma
	12.1. Plasma Action Values		14.1. Plasma Action Values
	A new registry is established for Plasma server action identifiers		A new registry is established for Plasma server action identifiers
	using the tag "action-id". The full urn for the registry is		using the tag "action-id". The full urn for the registry is
	"urn:ietf:params:xml:ns:plasma:actions". This registry operates		"urn:ietf:params:xml:ns:plasma:actions". This registry operates
	under a specification required policy. All entries in this registry		under a specification required policy. All entries in this registry
	require the following elements:		require the following elements:
	o A string in camel case which identifies the action to be		o A string in camel case which identifies the action to be
	performed.		performed.
	skipping to change at page 43, line 6 ¶		skipping to change at page 50, line 6 ¶
	+-----------------+-------------------------+------------------+		+-----------------+-------------------------+------------------+
	When these actions are placed in an xacml:Request,		When these actions are placed in an xacml:Request,
	o the Category is		o the Category is
	"urn:oasis:names:tc:xacml:3.0:attribute-category:action",		"urn:oasis:names:tc:xacml:3.0:attribute-category:action",
	o the AttributeId is "urn:ietf:params:xml:ns:plasma:actions",		o the AttributeId is "urn:ietf:params:xml:ns:plasma:actions",
	o the DataType is "http://www.w3.org/2001/XMLSchema#string"		o the DataType is "http://www.w3.org/2001/XMLSchema#string"
	12.2. non		14.2. non
	Define a new data name space urn:ietf:params:xml:ns:plasma:data-id		Define a new data name space urn:ietf:params:xml:ns:plasma:data-id
	CMSToken		CMSToken
	ChannelBinding		ChannelBinding
	SMIME-Capabilities		SMIME-Capabilities
	Define a new name space for status codes at		Define a new name space for status codes at
	skipping to change at page 44, line 5 ¶		skipping to change at page 51, line 5 ¶
	We define a schema in appendix A at		We define a schema in appendix A at
	urn:ietf:params:xml:schema:plasma-RFCTBD		urn:ietf:params:xml:schema:plasma-RFCTBD
	Define a new Status Code for use in the Status URI field.		Define a new Status Code for use in the Status URI field.
	urn:ietf:???:plasma:status:gss-api-response - This status is		urn:ietf:???:plasma:status:gss-api-response - This status is
	returned only with Indefinite responses. Indicates a GSS-API		returned only with Indefinite responses. Indicates a GSS-API
	response object was returned in the GSSAPIResponse token type.		response object was returned in the GSSAPIResponse token type.
	Will return until authentication has been completed.		Will return until authentication has been completed.
	13. Open Issues		14.3. Port Assignment
			We request that IANA assign a new port for the use of this protocol.
			Service name: plasma
			Port Number: TBD1
			Transport Protocol: TCP
			Description: Plasma Service Protocol
			Reference: This document
			Assignee: iesg@ietf.org
			Contact: chair@ietf.org
			Notes: The protocol requires that TLS be used to communicate over
			this port. There is no provision for unsecure messages to be sent to
			this protocol.
			15. Open Issues
	List of Open Issues:		List of Open Issues:
	o JLS: URL definitions - do we need a new schema or do we just		o JLS: URL definitions - do we need a new schema or do we just
	overload https? For our URLs - do we require that they be passed		overload https? For our URLs - do we require that they be passed
	through the internationalization step first? Probably should		through the internationalization step first? Probably should
	since the locale information is on the server and the client might		since the locale information is on the server and the client might
	not agree.		not agree.
	o JLS: Should we require that any SignatureProperty be present for		o JLS: Should we require that any SignatureProperty be present for
	skipping to change at page 45, line 5 ¶		skipping to change at page 52, line 30 ¶
	RetrievalMethod with a transform, but that does not seem correct.		RetrievalMethod with a transform, but that does not seem correct.
	May need to define a new KeyInfo structure to do it.		May need to define a new KeyInfo structure to do it.
	o JLS: Should X.509 certificates and attribute certificates be fully		o JLS: Should X.509 certificates and attribute certificates be fully
	specified as an authentication method?		specified as an authentication method?
	o JLS: Should a SignerInfo attribute be placed under the access-		o JLS: Should a SignerInfo attribute be placed under the access-
	subject Category for a senders version and under Environment for a		subject Category for a senders version and under Environment for a
	machine version? Currently both are under Data		machine version? Currently both are under Data
	14. References		o JLS: Need an obligation to say that CEK must be encrypted. Do we
			also need to have recipient info structures encrypted?
	14.1. Normative References		16. References
			16.1. Normative References
	[ABFAB] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the		[ABFAB] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
	Extensible Authentication Protocol", Work In		Extensible Authentication Protocol", Work In
	Progress draft-ietf-abfab-gss-eap-04, Oct 2011.		Progress draft-ietf-abfab-gss-eap-04, Oct 2011.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[EPS-CMS] Schaad, J., "Email Policy Service ASN.1 Processing", Work		[EPS-CMS] Schaad, J., "Email Policy Service ASN.1 Processing", Work
	In Progress draft-schaad-plamsa-cms, Jan 2011.		In Progress draft-schaad-plamsa-cms, Jan 2011.
	skipping to change at page 46, line 13 ¶		skipping to change at page 54, line 13 ¶
	2.0-os, March 2005.		2.0-os, March 2005.
	[RFC5705] Rescorla, E., "Keying Material Exporters for Transport		[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
	Layer Security (TLS)", RFC 5705, March 2010.		Layer Security (TLS)", RFC 5705, March 2010.
	[SMIME-MSG]		[SMIME-MSG]
	Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet		Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
	Mail Extensions (S/MIME) Version 3.2 Message		Mail Extensions (S/MIME) Version 3.2 Message
	Specification", RFC 5751, January 2010.		Specification", RFC 5751, January 2010.
	14.2. Informative References		16.2. Informative References
	[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.		(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence		[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
	Record Syntax (ERS)", RFC 4998, August 2007.		Record Syntax (ERS)", RFC 4998, August 2007.
			[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
			"Transport Layer Security (TLS) Session Resumption without
			Server-Side State", RFC 5077, January 2008.
	[SAML-XACML]		[SAML-XACML]
	Anderson, A. and H. Lockhart, "SAML 2.0 profile of XACML		Anderson, A. and H. Lockhart, "SAML 2.0 profile of XACML
	v2.0", OASIS Standard access_control-xacml-2.0-saml-		v2.0", OASIS Standard access_control-xacml-2.0-saml-
	profile-spec-os.pdf, February 2005.		profile-spec-os.pdf, February 2005.
			[PlasmaBasicPolicy]
			Anon, A., "IETF Defined Plasma Policies", February 2005.
	[SOAP11] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,		[SOAP11] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
	Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer,		Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer,
	"Simple Object Access Protocol (SOAP) 1.1", W3C NOTE NOTE-		"Simple Object Access Protocol (SOAP) 1.1", W3C NOTE NOTE-
	SOAP-20000508, May 2000.		SOAP-20000508, May 2000.
	[SOAP12] Lafon, Y., Gudgin, M., Hadley, M., Moreau, J., Mendelsohn,		[SOAP12] Lafon, Y., Gudgin, M., Hadley, M., Moreau, J., Mendelsohn,
	N., Karmarkar, A., and H. Nielsen, "SOAP Version 1.2 Part		N., Karmarkar, A., and H. Nielsen, "SOAP Version 1.2 Part
	1: Messaging Framework (Second Edition)", World Wide Web		1: Messaging Framework (Second Edition)", World Wide Web
	Consortium Recommendation REC-soap12-part1-20070427,		Consortium Recommendation REC-soap12-part1-20070427,
	April 2007,		April 2007,
	skipping to change at page 47, line 47 ¶		skipping to change at page 55, line 47 ¶
	[anchor23] Trevor: What about audit obligatiouns		[anchor23] Trevor: What about audit obligatiouns
	[anchor24] Trevor: Should we ignore it if present?		[anchor24] Trevor: Should we ignore it if present?
	[anchor25] JLS: I don't think we need to say anything about looking		[anchor25] JLS: I don't think we need to say anything about looking
	at it or ignoring it. While it would be something for		at it or ignoring it. While it would be something for
	debugging, as a general rule the client does not care		debugging, as a general rule the client does not care
	which policies where evaluated and passed to grant		which policies where evaluated and passed to grant
	access.		access.
	[anchor27] JLS: I keep wondering if we need to define a set of		[anchor27] Trevor: Something missing.
	minimal structures that can be used for options so that
	the entirety is not pushed off onto the client and server
	to parse and understand the structures.
	[anchor28] Trevor: Something missing.
	[anchor29] Trevor: did not think you have a revocation mechanism in		[anchor28] Trevor: did not think you have a revocation mechanism in
	SAML		SAML
	[anchor30] jls: I need to think this case out a bit more - I want to		[anchor33] jls: We may want to require that a reply token always be
	be able to supply multiple CMS tokens at one time,		returned instead of just returning it on demand.
	however I am not sure if that is do able because if you
	get a success for one token and a deny for another token
	there is no way to handle that in the xacml:Response.
	Appendix A. XML Schema		Appendix A. XML Schema
	This appendix represents the entirety of the XML Schema for Plasma		This appendix represents the entirety of the XML Schema for Plasma
	documents.		documents.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!-- edited with XMLSpy v2007 sp2 (http://www.altova.com) by James Schaad (exmsft) -->		<!-- edited with XMLSpy v2007 sp2 (http://www.altova.com) by James Schaad (exmsft) -->
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:eps="urn:ietf:schema:plasma:1.0" xmlns:ds2="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" targetNamespace="urn:ietf:schema:plasma:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified">		<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:eps="urn:ietf:schema:plasma:1.0" xmlns:ds2="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" targetNamespace="urn:ietf:schema:plasma:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:annotation>		<xs:annotation>
	skipping to change at page 49, line 35 ¶		skipping to change at page 57, line 35 ¶
	<xs:attribute name="Version" type="xs:string" default="1.0"/>		<xs:attribute name="Version" type="xs:string" default="1.0"/>
	</xs:complexType>		</xs:complexType>
	<xs:element name="PlasmaResponse" type="eps:ResponseType"/>		<xs:element name="PlasmaResponse" type="eps:ResponseType"/>
	<xs:complexType name="ResponseType">		<xs:complexType name="ResponseType">
	<xs:sequence>		<xs:sequence>
	<xs:element ref="xacml:Response"/>		<xs:element ref="xacml:Response"/>
	<xs:element ref="eps:PlasmaReturnToken" minOccurs="0" maxOccurs="unbounded"/>		<xs:element ref="eps:PlasmaReturnToken" minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="Version" type="xs:string" default="1.0"/>		<xs:attribute name="Version" type="xs:string" default="1.0"/>
	</xs:complexType>		</xs:complexType>
	<xs:element name="PlasmaReturnToken" type="eps:PlasmaReturnTokenType" abstract="true"/>		<xs:element name="PlasmaReturnToken" type="eps:PlasmaReturnTokenType"/>
	<xs:complexType name="PlasmaReturnTokenType" abstract="true">		<xs:complexType name="PlasmaReturnTokenType" abstract="true">
	<xs:attribute name="DecisionId"/>		<xs:attribute name="DecisionId" type="xs:string"/>
	</xs:complexType>		</xs:complexType>
	<!-- <xs:element name="RequestRoles">		<!-- <xs:element name="RequestRoles">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element ref="eps:Authentication" minOccurs="0"/>		<xs:element ref="eps:Authentication" minOccurs="0"/>
	<xs:element name="Identity" type="xs:string"/>		<xs:element name="Identity" type="xs:string"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:element name="RequestMessageData">		<xs:element name="RequestMessageData">
	skipping to change at page 50, line 33 ¶		skipping to change at page 58, line 33 ¶
	<xs:element ref="ds2:Signature"/>		<xs:element ref="ds2:Signature"/>
	<xs:element name="Other">		<xs:element name="Other">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:any namespace="##other"/>		<xs:any namespace="##other"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:choice>		</xs:choice>
	</xs:complexType>		</xs:complexType>
	<xs:element name="RoleToken" type="eps:RoleTokenType"/>		<xs:complexType name="RoleToken">
	<xs:complexType name="RoleTokenType">
	<xs:complexContent>		<xs:complexContent>
	<xs:extension base="eps:PlasmaReturnTokenType">		<xs:extension base="eps:PlasmaReturnTokenType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Name" type="xs:string"/>		<xs:element name="Name" type="xs:string"/>
	<xs:element name="PDP" type="xs:anyURI" maxOccurs="unbounded"/>		<xs:element name="PDP" type="xs:anyURI" maxOccurs="unbounded"/>
	<xs:choice>		<xs:choice>
	<xs:element name="PolicyList">		<xs:element name="PolicyList">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element name="Policy" type="eps:PolicyType" maxOccurs="unbounded"/>		<xs:element name="Policy" type="eps:PolicyType" maxOccurs="unbounded"/>
	skipping to change at page 51, line 46 ¶		skipping to change at page 59, line 45 ¶
	<xs:enumeration value="and"/>		<xs:enumeration value="and"/>
	<xs:enumeration value="or"/>		<xs:enumeration value="or"/>
	<xs:enumeration value="except"/>		<xs:enumeration value="except"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:element name="Leaf" type="eps:LeafType"/>		<xs:element name="Leaf" type="eps:LeafType"/>
	<xs:complexType name="LeafType">		<xs:complexType name="LeafType">
	<xs:sequence>		<xs:sequence>
	<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>		<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="Label" type="xs:string" use="required"/>		<xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>
	</xs:complexType>		</xs:complexType>
	<xs:element name="MessageTokenRequest" type="eps:MessageTokenRequestType"/>		<xs:element name="GetCMSToken" type="eps:CMSTokenRequestType"/>
	<xs:complexType name="MessageTokenRequestType">		<xs:complexType name="CMSTokenRequestType">
	<xs:sequence>		<xs:sequence>
	<xs:choice>		<xs:choice>
	<xs:element ref="eps:Label"/>		<xs:element ref="eps:Label"/>
	<xs:element ref="eps:Leaf"/>		<xs:element ref="eps:Leaf"/>
	</xs:choice>		</xs:choice>
	<xs:element name="Hash">		<xs:element name="Hash">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element ref="ds2:DigestMethod"/>		<xs:element ref="ds2:DigestMethod"/>
	<xs:element ref="ds2:DigestValue"/>		<xs:element ref="ds2:DigestValue"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:element name="Recipient" type="eps:RecipientInfoType" minOccurs="0" maxOccurs="unbounded"/>		<xs:element name="Recipient" type="eps:RecipientInfoType" minOccurs="0" maxOccurs="unbounded"/>
	<xs:element name="KEK" minOccurs="0">		<xs:element name="CEK" type="xs:hexBinary" minOccurs="0"/>
	<xs:complexType>
	<xs:sequence>
	<xs:element name="Identifer" type="xs:hexBinary"/>
	<xs:element name="Value" type="xs:hexBinary"/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:element name="RecipientInfo" type="eps:RecipientInfoType"/>		<xs:element name="RecipientInfo" type="eps:RecipientInfoType"/>
	<xs:complexType name="RecipientInfoType">		<xs:complexType name="RecipientInfoType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Subject" maxOccurs="unbounded">		<xs:element name="Subject" maxOccurs="unbounded">
	<xs:complexType>		<xs:complexType>
	<xs:simpleContent>		<xs:simpleContent>
	<xs:extension base="xs:anySimpleType">		<xs:extension base="xs:anySimpleType">
	<xs:attribute name="type" type="xs:string" use="required"/>		<xs:attribute name="type" type="xs:string" use="required"/>
	</xs:extension>		</xs:extension>
	</xs:simpleContent>		</xs:simpleContent>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:element name="LockBox" type="xs:hexBinary"/>		<xs:element name="LockBox" type="xs:base64Binary"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:element name="CMSKey" type="eps:CMSKeyResponseType"/>		<xs:element name="CMSKey" type="eps:CMSKeyResponseType"/>
	<xs:complexType name="CMSKeyResponseType">		<xs:complexType name="CMSKeyResponseType">
	<xs:complexContent>		<xs:complexContent>
	<xs:extension base="eps:PlasmaReturnTokenType">		<xs:extension base="eps:PlasmaReturnTokenType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="DisplayString" type="xs:string"/>		<xs:element name="DisplayString" type="xs:string"/>
	<xs:choice>		<xs:choice>
	<xs:element name="KEK" type="xs:hexBinary"/>		<xs:element name="CEK" type="xs:hexBinary"/>
	<xs:element name="KEKIdentifier" type="xs:hexBinary"/>		<xs:element ref="eps:RecipientInfo"/>
	<xs:element ref="eps:RecipientInfo"/>		</xs:choice>
	</xs:choice>		<xs:element name="ResponseRoleToken" type="eps:RoleToken" minOccurs="0"/>
	<xs:element ref="eps:RoleToken" minOccurs="0"/>		<xs:element name="EncryptionRequestor" type="xs:string"/>
	<xs:element name="EncryptionRequestor" type="xs:string"/>
	</xs:sequence>		</xs:sequence>
	</xs:extension>		</xs:extension>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	<xs:element name="CMSToken" type="eps:CMSTokenResponseType"/>		<xs:element name="CMSToken" type="eps:CMSTokenResponseType"/>
	<xs:complexType name="CMSTokenResponseType">		<xs:complexType name="CMSTokenResponseType">
	<xs:complexContent>		<xs:complexContent>
	<xs:extension base="eps:PlasmaReturnTokenType"/>		<xs:extension base="eps:PlasmaReturnTokenType">
			<xs:sequence>
			<xs:element name="RecipientInfo" maxOccurs="unbounded">
			<xs:complexType>
			<xs:simpleContent>
			<xs:extension base="xs:base64Binary">
			<xs:attribute name="CMSType" type="xs:string"/>
			</xs:extension>
			</xs:simpleContent>
			</xs:complexType>
			</xs:element>
			</xs:sequence>
			</xs:extension>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	</xs:schema>		</xs:schema>
	Appendix B. Example: Get Roles Request		Appendix B. Example: Get Roles Request
	This section provides an example of a request message to obtain the		This section provides an example of a request message to obtain the
	set of roles for an individual named 'bart@simpsons.com'. The		set of roles for an individual named 'bart@simpsons.com'. The
	authentication provided in this is a SAML statement included in the		authentication provided in this is a SAML statement included in the
	SAML_Collection element.		SAML_Collection element.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<PlasmaRequest xmlns="urn:ietf:schema:plasma:1.0"		<PlasmaRequest xmlns="urn:ietf:schema:plasma:1.0"
	xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">		xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
			xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
			xsi:schemaLocation="urn:ietf:schema:plasma:1.0 C:\ietf\drafts\Schema\Plasma.xsd" >
	<Authentication>		<Authentication>
	<SAML_Collection>...</SAML_Collection>		<WS-Token>123456</WS-Token>
			<!-- <saml:Assertion>....</saml:Assertion> -->
	</Authentication>		</Authentication>
	<xacml:Request CombinedDecision="false" ReturnPolicyIdList="false">		<xacml:Request CombinedDecision="false" ReturnPolicyIdList="false">
	<xacml:Attributes Category="urn:oasis:names:tc:xacml:1.0:subect-category:access-subject">
	<xacml:Attribute IncludeInResult="false"
	AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
	<xacml:AttributeValue
	DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name">bart@simpsons.com</xacml:AttributeValue>
	</xacml:Attribute>
	</xacml:Attributes>
	<xacml:Attributes Category="urn:oasis:names:tc:xaml:3.0:attribute-catagory:action">		<xacml:Attributes Category="urn:oasis:names:tc:xaml:3.0:attribute-catagory:action">
	<xacml:Attribute IncludeInResult="false" AttributeId="urn:plasma:action-id">		<xacml:Attribute IncludeInResult="false" AttributeId="urn:plasma:action-id">
	<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GetRoleTokens</xacml:AttributeValue>		<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GetRoleTokens</xacml:AttributeValue>
	</xacml:Attribute>		</xacml:Attribute>
	</xacml:Attributes>		</xacml:Attributes>
			<xacml:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment">
			<xacml:Attribute AttributeId="urn:ietf:plasma:data:channel" IncludeInResult="false">
			<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#base64Binary">ABCDEFGH</xacml:AttributeValue>
			</xacml:Attribute>
			</xacml:Attributes>
	</xacml:Request>		</xacml:Request>
	</PlasmaRequest>		</PlasmaRequest>
	Appendix C. Example: Get Roles Response		Appendix C. Example: Get Roles Response
	This section provides an example response to a successful request for		This section provides an example response to a successful request for
	a role sets.		a role sets.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<PlasmaResponse xmlns="urn:ietf:schema:plasma:1.0"		<PlasmaResponse xmlns="urn:ietf:schema:plasma:1.0"
	xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"		xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
	xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"		xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"
	xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">		xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
			xsi:schemaLocation="urn:ietf:schema:plasma:1.0 C:\ietf\drafts\Schema\Plasma.xsd">
	<xacml:Response>		<xacml:Response>
	<xacml:Result>		<xacml:Result>
	<xacml:Decision>Permit</xacml:Decision>		<xacml:Decision>Permit</xacml:Decision>
	</xacml:Result>		</xacml:Result>
	</xacml:Response>		</xacml:Response>
	<PlasmaTokens>		<PlasmaReturnToken xsi:type="RoleToken">
	<PlasmaToken>		<Name>Example Role Name</Name>
	<PDP>https://pdp.example.com/companyPolicies</PDP>		<PDP>https://pdp.example.com/companyPolicies</PDP>
	<PolicyList>		<PolicyList>
	<Policy>		<Policy PolicyId="urn:example:policies:confidential">
	<Name>Company Confidential</Name>		<Name>Company Confidential</Name>
	<Identifier>urn:example:policies:confidential</Identifier>
	</Policy>		</Policy>
	<Policy>		<Policy PolicyId="urn:example:policies:plasma">
	<Name>Plasma Project</Name>		<Name>Plasma Project</Name>
	<Identifier>urn:example:policies:plasma</Identifier>
	</Policy>		</Policy>
	</PolicyList>		</PolicyList>
	<wst:RequestSecurityTokenResponse>		<wst:RequestSecurityTokenResponse>
	<wst:TokenType>urn:plasma:roleToken</wst:TokenType>		<wst:TokenType>urn:plasma:roleToken</wst:TokenType>
	<wst:RequestedSecruityToken>....</wst:RequestedSecruityToken>		<wst:RequestedSecruityToken>....</wst:RequestedSecruityToken>
	<wst:Entropy><wst:BinarySecret>12345678</wst:BinarySecret></wst:Entropy>		<wst:Entropy><wst:BinarySecret>12345678</wst:BinarySecret></wst:Entropy>
	<wst:Lifetime><wsu:Expires>2012-02-01T00:00:00</wsu:Expires></wst:Lifetime>		<wst:Lifetime><wsu:Expires>2012-02-01T00:00:00</wsu:Expires></wst:Lifetime>
	</wst:RequestSecurityTokenResponse>		</wst:RequestSecurityTokenResponse>
	</PlasmaToken>		</PlasmaReturnToken>
	</PlasmaTokens>
	</PlasmaResponse>		</PlasmaResponse>
			In this example a role is returned that has two different policies
			that can be used by that role. Along with the role token, a binary
			secret is returned that is to be used in proving that the same entity
			is returning to use the roles.
	Appendix D. Example: Get CMS Token Request		Appendix D. Example: Get CMS Token Request
	This section contains an example of a request from a client to a		This section contains an example of a request from a client to a
	server for a CMS message token to be issued. The authentication for		server for a CMS message token to be issued. The authentication for
	the request is provided by using a WS-Trust token previously issued		the request is provided by using a WS-Trust token previously issued
	as part of a role request/response dialog. The request contains the		as part of a role request/response dialog. The request contains the
	following elements:		following elements:
	o A complex rule set is requested where permission to is to be		o A complex rule set is requested where permission to is to be
	granted to anyone who meets either of the two policies given.		granted to anyone who meets either of the two policies given.
	skipping to change at page 57, line 9 ¶		skipping to change at page 65, line 9 ¶
	info structure are skipped but it would be any encoding of a		info structure are skipped but it would be any encoding of a
	RecipientInfo structure from CMS.		RecipientInfo structure from CMS.
	o A generic key encryption key is provided for any other subject who		o A generic key encryption key is provided for any other subject who
	meets the policies specified.		meets the policies specified.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<PlasmaRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		<PlasmaRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:schema:plasma:1.0 C:\ietf\drafts\Schema\Plasma.xsd"		xsi:schemaLocation="urn:ietf:schema:plasma:1.0 C:\ietf\drafts\Schema\Plasma.xsd"
	xmlns="urn:ietf:schema:plasma:1.0"		xmlns="urn:ietf:schema:plasma:1.0"
			xmlns:ds2="http://www.w3.org/2000/09/xmldsig#"
	xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">		xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
	<Authentication>		<Authentication>
	<WS_Token>123456</WS_Token>		<WS-Token>123456</WS-Token>
	</Authentication>		</Authentication>
	<xacml:Request CombinedDecision="false" ReturnPolicyIdList="false">		<xacml:Request CombinedDecision="false" ReturnPolicyIdList="false">
	<xacml:Attributes Category="urn:oasis:names:tc:xaml:3.0:attribute-catagory:action">		<xacml:Attributes Category="urn:oasis:names:tc:xaml:3.0:attribute-catagory:action">
	<xacml:Attribute IncludeInResult="false" AttributeId="urn:plasma:action-id">		<xacml:Attribute IncludeInResult="false" AttributeId="urn:plasma:action-id">
	<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GetCMSToken</xacml:AttributeValue>		<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GetCMSToken</xacml:AttributeValue>
	</xacml:Attribute>		</xacml:Attribute>
	</xacml:Attributes>		</xacml:Attributes>
	<xacml:Attributes Category="urn:ietf:plasma:attribute-category:data">		<xacml:Attributes Category="urn:ietf:plasma:attribute-category:data">
	<xacml:Attribute AttributeId="urn:plasma:data-id" IncludeInResult="false">		<xacml:Attribute AttributeId="urn:plasma:data-id" IncludeInResult="false">
	<xacml:AttributeValue DataType="xml">		<xacml:AttributeValue DataType="xml">
	<MessageTokenRequest>		<GetCMSToken>
	<Label CombiningRule="or">		<Label CombiningRule="or">
	<Leaf Label="urn:example:policies:confidential"/>		<Leaf Label="urn:example:policies:confidential"/>
	<Leaf Label="urn:example:policies:plasma"/>		<Leaf Label="urn:example:policies:plasma"/>
	</Label>		</Label>
	<RecipientInfo>		<Hash>
			<ds2:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds2:DigestMethod>
			<ds2:DigestValue>ABCDEFG0</ds2:DigestValue>
			</Hash>
			<Recipient>
	<Subject type="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name">		<Subject type="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name">
	lisa@simpsons.com		lisa@simpsons.com
	</Subject>		</Subject>
	<LockBox>FF33eeddccaa002234</LockBox>		<LockBox>FF33eeddccaa002234</LockBox>
	</RecipientInfo>		</Recipient>
	<KEK>AB123456</KEK>		<CEK>AB123456</CEK>
	</MessageTokenRequest>		</GetCMSToken>
	</xacml:AttributeValue>		</xacml:AttributeValue>
	</xacml:Attribute>		</xacml:Attribute>
	</xacml:Attributes>		</xacml:Attributes>
	</xacml:Request>		</xacml:Request>
	</PlasmaRequest>		</PlasmaRequest>
	Appendix E. Example: Get CMS Token Response		Appendix E. Example: Get CMS Token Response
	This section contains an example of a response from a server to a		This section contains an example of a response from a server to a
	client for a CMS message token to be issued. The token is returned		client for a CMS message token to be issued. The token is returned
	in the CMSToken element. This element would then be placed into the		in the CMSToken element. This element would then be placed into the
	skipping to change at page 58, line 21 ¶		skipping to change at page 66, line 21 ¶
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<PlasmaResponse xmlns="urn:ietf:schema:plasma:1.0"		<PlasmaResponse xmlns="urn:ietf:schema:plasma:1.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:schema:plasma:1.0 C:\ietf\drafts\Schema\Plasma.xsd"		xsi:schemaLocation="urn:ietf:schema:plasma:1.0 C:\ietf\drafts\Schema\Plasma.xsd"
	xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">		xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
	<xacml:Response>		<xacml:Response>
	<xacml:Result>		<xacml:Result>
	<xacml:Decision>Permit</xacml:Decision>		<xacml:Decision>Permit</xacml:Decision>
	</xacml:Result>		</xacml:Result>
	</xacml:Response>		</xacml:Response>
	<CMSToken>3425342352343243</CMSToken>		<PlasmaReturnToken xsi:type="CMSTokenResponseType">
			<RecipientInfo>3425342352343243</RecipientInfo>
			</PlasmaReturnToken>
	</PlasmaResponse>		</PlasmaResponse>
	Appendix F. Example: Get CMS Key Request		Appendix F. Example: Get CMS Key Request
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<PlasmaRequest xmlns="urn:ietf:schema:plasma:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		<PlasmaRequest xmlns="urn:ietf:schema:plasma:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:schema:plasma:1.0 C:\ietf\drafts\Schema\Plasma.xsd"		xsi:schemaLocation="urn:ietf:schema:plasma:1.0 C:\ietf\drafts\Schema\Plasma.xsd"
			xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
	xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">		xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
	<Authentication>		<Authentication>
	<SAML_Collection>....</SAML_Collection>		<!-- <saml:Assertion></saml:Assertion> -->
			<GSSAPI></GSSAPI>
	</Authentication>		</Authentication>
	<xacml:Request CombinedDecision="false" ReturnPolicyIdList="false">		<xacml:Request CombinedDecision="false" ReturnPolicyIdList="false">
	<xacml:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-catagory:action">		<xacml:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-catagory:action">
	<xacml:Attribute AttributeId="urn:plasma:action-id" IncludeInResult="false">		<xacml:Attribute AttributeId="urn:plasma:action-id" IncludeInResult="false">
	<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">ParseCMSToken</xacml:AttributeValue>		<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">ParseCMSToken</xacml:AttributeValue>
	</xacml:Attribute>		</xacml:Attribute>
	<xacml:Attribute AttributeId="urn:plasma:action-id" IncludeInResult="false">		<xacml:Attribute AttributeId="urn:plasma:action-id" IncludeInResult="false">
	<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GetReplyToken</xacml:AttributeValue>		<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GetReplyToken</xacml:AttributeValue>
	</xacml:Attribute>		</xacml:Attribute>
	</xacml:Attributes>		</xacml:Attributes>
	<xacml:Attributes Category="urn:ietf:plasma:attribute-category:data">		<xacml:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:data">
	<xacml:Attribute AttributeId="urn:plasma:data-id" IncludeInResult="false">		<xacml:Attribute AttributeId="urn:plasma:data-id:CMSToken" IncludeInResult="false">
	<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#hexBinary">AABBDDEEFF1122344</xacml:AttributeValue>		<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#base64Binary">AABBDDEEFF1122344</xacml:AttributeValue>
	</xacml:Attribute>		</xacml:Attribute>
	</xacml:Attributes>		</xacml:Attributes>
	</xacml:Request>		</xacml:Request>
	</PlasmaRequest>		</PlasmaRequest>
	Appendix G. Example: Get CMS KeyResponse		Appendix G. Example: Get CMS KeyResponse
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<PlasmaResponse xmlns="urn:ietf:schema:plasma:1.0"		<PlasmaResponse xmlns="urn:ietf:schema:plasma:1.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:schema:plasma:1.0 C:\ietf\drafts\Schema\Plasma.xsd"		xsi:schemaLocation="urn:ietf:schema:plasma:1.0 C:\ietf\drafts\Schema\Plasma.xsd"
	xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"		xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
	xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"		xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"
	xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">		xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
	<xacml:Response>		<xacml:Response>
	<xacml:Result>		<xacml:Result>
	<xacml:Decision>Permit</xacml:Decision>		<xacml:Decision>Permit</xacml:Decision>
	</xacml:Result>		</xacml:Result>
	</xacml:Response>		</xacml:Response>
	<CMSKey>		<PlasmaReturnToken xsi:type="CMSKeyResponseType">
	<DisplayString>Company Confidential</DisplayString>		<DisplayString>Company Confidential</DisplayString>
	<KEK>3425342352343243</KEK>		<CEK>3425342352343243</CEK>
	<PlasmaToken>		<ResponseRoleToken>
			<Name>Message Response Role</Name>
	<PDP>https://pdp.example.com/companyPolicies</PDP>		<PDP>https://pdp.example.com/companyPolicies</PDP>
	<Label CombiningRule="or">		<Label CombiningRule="or">
	<Leaf Label="urn:example:policies:confidential"/>		<Leaf PolicyId="urn:example:policies:confidential"/>
	<Leaf Label="urn:example:policies:plasma"/>		<Leaf PolicyId="urn:example:policies:plasma"/>
	</Label>		</Label>
	<wst:RequestSecurityTokenResponse>		<wst:RequestSecurityTokenResponse>
	<wst:TokenType>urn:plasma:roleToken</wst:TokenType>		<wst:TokenType>urn:plasma:roleToken</wst:TokenType>
	<wst:RequestedSecurityToken>....</wst:RequestedSecurityToken>		<wst:RequestedSecurityToken>ABCDEF</wst:RequestedSecurityToken>
	<wst:Lifetime><wsu:Expires>2012-02-01T00:00:00</wsu:Expires></wst:Lifetime>		<wst:Lifetime><wsu:Expires>2012-02-01T00:00:00</wsu:Expires></wst:Lifetime>
	</wst:RequestSecurityTokenResponse>		</wst:RequestSecurityTokenResponse>
	</PlasmaToken>		</ResponseRoleToken>
	</CMSKey>		</PlasmaReturnToken>
	</PlasmaResponse>		</PlasmaResponse>
	Appendix H. Enabling the MultiRequests option		Appendix H. Enabling the MultiRequests option
	NOTE: RFC Editor please remove this section prior to publication.		NOTE: RFC Editor please remove this section prior to publication.
	This section exists as a note to the author to make sure that it can		This section exists as a note to the author to make sure that it can
	be done. It will be published as a separate document if desired.		be done. It will be published as a separate document if desired.
	One of the issues in doing multiple requests in a single message is		One of the issues in doing multiple requests in a single message is
	the issue of correlation between the request and the results. We		the issue of correlation between the request and the results. We
	have make this issue even worse by the fact that we are return		have make this issue even worse by the fact that we are return
End of changes. 107 change blocks.
	316 lines changed or deleted		639 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/