< draft-ietf-sip-saml-02.txt		draft-ietf-sip-saml-03.txt >
	SIP H. Tschofenig		SIP H. Tschofenig
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Intended status: Standards Track J. Hodges		Updates: 4474 (if approved) J. Hodges
	Expires: November 29, 2007 J. Peterson		Intended status: Standards Track J. Peterson
	NeuStar, Inc.		Expires: May 21, 2008 NeuStar, Inc.
	J. Polk		J. Polk
	Cisco		Cisco
	D. Sicker		D. Sicker
	CU Boulder		CU Boulder
	May 28, 2007		November 18, 2007
	SIP SAML Profile and Binding		SIP SAML Profile and Binding
	draft-ietf-sip-saml-02.txt		draft-ietf-sip-saml-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 29, 2007.		This Internet-Draft will expire on May 21, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document specifies a Session Initiation Protocol (SIP) profile		This document specifies a Session Initiation Protocol (SIP) profile
	of Security Assertion Markup Language (SAML) as well as a SAML SIP		of Security Assertion Markup Language (SAML) as well as a SAML SIP
	binding. The defined SIP SAML Profile composes with the mechanisms		binding. The defined SIP SAML Profile composes with the mechanisms
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 9		4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 9
	5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 11		5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 11
	6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 13		6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 13
	6.1. AS-driven SIP SAML URI-based Attribute Assertion		6.1. AS-driven SIP SAML URI-based Attribute Assertion
	Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 13		Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 13
	6.1.1. Required Information . . . . . . . . . . . . . . . . . 13		6.1.1. Required Information . . . . . . . . . . . . . . . . . 13
	6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 13		6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 13
	6.1.3. Profile Description . . . . . . . . . . . . . . . . . 17		6.1.3. Profile Description . . . . . . . . . . . . . . . . . 17
	6.1.4. Assertion Profile Description . . . . . . . . . . . . 20		6.1.4. Assertion Profile Description . . . . . . . . . . . . 20
	6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 22		6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 22
	7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 24		6.2. The TBD "call-by-value" Profile . . . . . . . . . . . . . 24
	7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 24		7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 25
	8. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 25		7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 25
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 30		8. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 26
	9.1. Man-in-the-middle Attacks and Stolen Assertions . . . . . 30		9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	9.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 31		9.1. Man-in-the-middle Attacks and Stolen Assertions . . . . . 31
	9.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 31		9.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 32
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32		9.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 32
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
	13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36		13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 36		14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	14.2. Informative References . . . . . . . . . . . . . . . . . . 37		14.1. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 37
	Appendix A. Appendix: Use-case Scenarios . . . . . . . . . . . . 40		14.2. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 37
	A.1. PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 40		15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	A.2. SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 41		15.1. Normative References . . . . . . . . . . . . . . . . . . . 38
	A.3. Compensation using SIP and SAML . . . . . . . . . . . . . 43		15.2. Informative References . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
	Intellectual Property and Copyright Statements . . . . . . . . . . 46		Intellectual Property and Copyright Statements . . . . . . . . . . 43
	1. Introduction		1. Introduction
	This document specifies composition of the Security Assertion Markup		This document specifies composition of the Security Assertion Markup
	Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate		Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate
	richer authorization mechanisms and enable "trait-based		richer authorization mechanisms and enable "trait-based
	authorization." Trait-based authorization is where one is authorized		authorization." Trait-based authorization is where one is authorized
	to make use of some resource based on roles or traits rather than		to make use of some resource based on roles or traits rather than
	ones identifier(s). Motivations for trait-based authorization, along		ones identifier(s). Motivations for trait-based authorization, along
	with use-case scenarios, are presented in [RFC4484].		with use-case scenarios, are presented in [RFC4484].
	skipping to change at page 13, line 7 ¶		skipping to change at page 13, line 7 ¶
	header containing the SIP Identity Assertion, and to supply a pointer		header containing the SIP Identity Assertion, and to supply a pointer
	to its domain certificate, having it point instead to a SAML		to its domain certificate, having it point instead to a SAML
	assertion conveying the domain certificate and possibly some user		assertion conveying the domain certificate and possibly some user
	profile attributes, does not significantly alter the first-order		profile attributes, does not significantly alter the first-order
	security considerations examined in [RFC4474]. This specification		security considerations examined in [RFC4474]. This specification
	provides some additional security considerations analysis below in		provides some additional security considerations analysis below in
	Section 9.		Section 9.
	6. SIP SAML Profiles		6. SIP SAML Profiles
	This section defines one SIP SAML profile:		This section defines two "SIP SAML profiles":
	The "AS-driven SIP SAML URI-based Attribute Assertion Fetch		o The "AS-driven SIP SAML URI-based Attribute Assertion Fetch
	Profile"		Profile"
			o The to-be-determined (TBD) "call-by-value" profile
	6.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile		6.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile
	6.1.1. Required Information		6.1.1. Required Information
	The information given in this section is similar to the info provided		The information given in this section is similar to the info provided
	when registering something, a MIME Media Type, say, with IANA. In		when registering something, a MIME Media Type, say, with IANA. In
	this case, it is for registering this profile with the OASIS SSTC.		this case, it is for registering this profile with the OASIS SSTC.
	See Section 2 "Specification of Additional Profiles" in		See Section 2 "Specification of Additional Profiles" in
	[OASIS.saml-profiles-2.0-os].		[OASIS.saml-profiles-2.0-os].
	skipping to change at page 24, line 5 ¶		skipping to change at page 24, line 5 ¶
	urn:oasis:names:tc:SAML:2.0:cm:sender-vouches		urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
	10. Verify that the SAML assertion contains an <Audience> element,		10. Verify that the SAML assertion contains an <Audience> element,
	and that its value matches the value of the addr-spec of the SIP		and that its value matches the value of the addr-spec of the SIP
	To header field.		To header field.
	11. Verify that the validity period denoted by the NotBefore and		11. Verify that the validity period denoted by the NotBefore and
	NotOnOrAfter attributes of the <Conditions> element meets the		NotOnOrAfter attributes of the <Conditions> element meets the
	requirements given in Section 6.1.4.1.3.		requirements given in Section 6.1.4.1.3.
			6.2. The TBD "call-by-value" Profile
			To-Be-Determined (TBD)
	7. SAML SIP Binding		7. SAML SIP Binding
	This section specifies one SAML SIP Binding at this time. Additional		This section specifies one SAML SIP Binding at this time. Additional
	bindings may be specified in future revisions of this specification.		bindings may be specified in future revisions of this specification.
	7.1. SAML HTTP-URI-based SIP Binding		7.1. SAML HTTP-URI-based SIP Binding
	This section specifies the "SAML HTTP-URI-based SIP Binding",		This section specifies the "SAML HTTP-URI-based SIP Binding",
	(SHUSB).		(SHUSB).
	skipping to change at page 36, line 5 ¶		skipping to change at page 37, line 5 ¶
	12. IANA Considerations		12. IANA Considerations
	[Editor's Note: A future version of this document will provide IANA		[Editor's Note: A future version of this document will provide IANA
	considerations.]		considerations.]
	13. Open Issues		13. Open Issues
	A list of open issues can be found at:		A list of open issues can be found at:
	http://www.tschofenig.com:8080/saml-sip/		http://www.tschofenig.com:8080/saml-sip/
	14. References		14. Change Log
	14.1. Normative References		RFC Editor - Please remove this section before publication.
			14.1. -02 to -03
			Denoted that this I-D is intended to update RFC4474 per SIP working
			group consensus at IETF-69. This is the tact adopted in order to
			address the impedance mismatch between the nature of the URIs
			specified as to be placed in the Identity-Info header field, and what
			is specified in RFC4474 as the allowable value of that header field.
			Added placeholder "TBD" section for a to-be-determined "call-by-
			value" profile, per SIP working group consensus at IETF-69.
			Removed use-case appendicies (per recollection of JHodges during
			IETF-69 discussion as being WG consensus, but such is not noted in
			the minutes).
			14.2. -00 to -02
			Will detail in -04 rev.
			15. References
			15.1. Normative References
	[OASIS.saml-bindings-2.0-os]		[OASIS.saml-bindings-2.0-os]
	Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.		Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
	Maler, "Bindings for the OASIS Security Assertion Markup		Maler, "Bindings for the OASIS Security Assertion Markup
	Language (SAML) V2.0", OASIS		Language (SAML) V2.0", OASIS
	Standard saml-bindings-2.0-os, March 2005.		Standard saml-bindings-2.0-os, March 2005.
	[OASIS.saml-core-2.0-os]		[OASIS.saml-core-2.0-os]
	Cantor, S., Kemp, J., Philpott, R., and E. Maler,		Cantor, S., Kemp, J., Philpott, R., and E. Maler,
	"Assertions and Protocol for the OASIS Security Assertion		"Assertions and Protocol for the OASIS Security Assertion
	skipping to change at page 37, line 29 ¶		skipping to change at page 39, line 29 ¶
	[RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig,		[RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig,
	"Trait-Based Authorization Requirements for the Session		"Trait-Based Authorization Requirements for the Session
	Initiation Protocol (SIP)", RFC 4484, August 2006.		Initiation Protocol (SIP)", RFC 4484, August 2006.
	[W3C.xmldsig-core]		[W3C.xmldsig-core]
	Eastlake, D., Reagle , J., and D. Solo, "XML-Signature		Eastlake, D., Reagle , J., and D. Solo, "XML-Signature
	Syntax and Processing", W3C Recommendation xmldsig-core,		Syntax and Processing", W3C Recommendation xmldsig-core,
	October 2000, <http://www.w3.org/TR/xmldsig-core/>.		October 2000, <http://www.w3.org/TR/xmldsig-core/>.
	14.2. Informative References		15.2. Informative References
	[I-D.ietf-sip-content-indirect-mech]		[I-D.ietf-sip-content-indirect-mech]
	Burger, E., "A Mechanism for Content Indirection in		Burger, E., "A Mechanism for Content Indirection in
	Session Initiation Protocol (SIP) Messages",		Session Initiation Protocol (SIP) Messages",
	draft-ietf-sip-content-indirect-mech-05 (work in		draft-ietf-sip-content-indirect-mech-05 (work in
	progress), October 2004.		progress), October 2004.
	[I-D.ietf-sipping-certs]		[I-D.ietf-sipping-certs]
	Jennings, C. and J. Peterson, "Certificate Management		Jennings, C. and J. Peterson, "Certificate Management
	Service for The Session Initiation Protocol (SIP)",		Service for The Session Initiation Protocol (SIP)",
	draft-ietf-sipping-certs-03 (work in progress),		draft-ietf-sipping-certs-03 (work in progress),
	March 2006.		March 2006.
	[I-D.jennings-sipping-pay]		[I-D.jennings-sipping-pay]
	Jennings, C., "Payment for Services in Session Initiation		Jennings, C., "Payment for Services in Session Initiation
	Protocol (SIP)", draft-jennings-sipping-pay-05 (work in		Protocol (SIP)", draft-jennings-sipping-pay-06 (work in
	progress), October 2006.		progress), July 2007.
	[I-D.peterson-message-identity]		[I-D.peterson-message-identity]
	Peterson, J., "Security Considerations for Impersonation		Peterson, J., "Security Considerations for Impersonation
	and Identity in Messaging Systems",		and Identity in Messaging Systems",
	draft-peterson-message-identity-00 (work in progress),		draft-peterson-message-identity-00 (work in progress),
	October 2004.		October 2004.
	[IANA.application.samlassertion-xml]		[IANA.application.samlassertion-xml]
	OASIS Security Services Technical Committee (SSTC),		OASIS Security Services Technical Committee (SSTC),
	"application/samlassertion+xml MIME Media Type		"application/samlassertion+xml MIME Media Type
	skipping to change at page 40, line 5 ¶		skipping to change at page 42, line 5 ¶
	B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693,		B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
	September 1999.		September 1999.
	[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute		[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
	Certificate Profile for Authorization", RFC 3281,		Certificate Profile for Authorization", RFC 3281,
	April 2002.		April 2002.
	[RFC3323] Peterson, J., "A Privacy Mechanism for the Session		[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
	Initiation Protocol (SIP)", RFC 3323, November 2002.		Initiation Protocol (SIP)", RFC 3323, November 2002.
	Appendix A. Appendix: Use-case Scenarios
	This Appendix explores message flows based on various use-case
	scenarios in [RFC4484], and from various discussions, to which SAML-
	based solutions are applied. Appendix A.2 shows a SIP conferencing
	scenario with role-based access control using SAML.
	Note that we present these scenarios as illustrations of possible
	SAML-based use cases in SIP. This document does not provide a
	detailed exposition of these scenarios -- that is left for addtional
	documents.
	A.1. PSTN-to-SIP Phone Call
	Alice, using a phone connected to the PSTN, wants to make a call to
	Bob, who resides in a SIP network. Her call is switched through the
	PSTN by means of PSTN signaling (outside the scope of this document)
	to the PSTN/SIP gateway. At the gateway, the call is converted from
	SS7 signaling to SIP signaling. Since Alice's PSTN phone was
	previously "authenticated" via PSTN signaling mechanisms, the gateway
	is able to assert her phone's identity (e.g., her telephone number)
	via SIP Identity and SAML-based mechanisms (e.g., in order to convey
	profile attributes) to Bob's SIP proxy, which also dereferences the
	URI in the Identity-Info header in order to obtain the SAML assertion
	and the PSTN/SIP Gateway's domain certificate. Alice's INVITE is
	then forwarded from the SIP/PSTN gateway to Bob's phone, and is
	secured via whatever means is locally established in Bob's
	administrative domain.
	+-----------+
	+----------------------+ | |
	| | SS7 | PSTN/SIP |
	| Public Switched |--------------------->| Gateway |
	| | | |
	| | | |
	| Telephone Network | +--+-----------+------+
	| ^ | | | ^ V |
	+---------+------------+ | | ^ V SIP-Ident |
	| SS7 | v ^ V +SAML |
	| | +--------+ |
	O | | Bob's | |
	O /|\ <----+----| SIP | |
	/|\ / \ SIP | | Proxy | |
	/ \ Bob | | | |
	Alice | +--------+ |
	| SIP based |
	| Network |
	+---------------------+
	Figure 7: PSTN to SIP call
	Note that the INVITE emitted by the PSTN/SIP gateway could
	alternatively be simply forwarded by Bob's SIP Proxy to Bob's phone,
	and Bob's phone could take on the SIP Identity "verifier" role, which
	is being played by Bob's SIP proxy in the figure.
	Whichever approach is employed is a decision local to Bob's
	administrative domain and can be made independently.
	A.2. SIP Conferencing
	This section is meant to foster discussion about the usage of SAML in
	the domain of conferencing. A user agent who routes its SIP message
	through the Authentication Service (Asserting Party) towards a
	conferencing server may want or need various of her profile
	attributes included and may also need to be authenticated by the
	conference server. The following properties could be provided by
	this procedure:
	o The user identity can be replaced to allow the user to be
	anonymous with regard to the Focus. This can be accomplished via
	[RFC3323] in combination with [RFC4474], per the latter, or,
	o The user identity could be asserted to the Focus, via [RFC4474]
	mechanisms, and/or,
	o the SAML assertion could provide additional user profile
	information such as group membership (belongs to the students,
	staff, faculty group of university X). This could, for non-
	identity-based authorization systems, imply certain rights.
	The corresponding SIP message flow (in high level detail) could have
	the following shape:
	+-----+ +-----------+ +-----------+
	| | | SIP Proxy | | Focus |
	|User | |(Asserting | | (Relying |
	| | | party) | | party) |
	+--+--+ +-----+-----+ +-----+-----+
	| INVITE | |
	|sip:conf-factory | INVITE |
	|------------------>| w/Identity hdr |
	| |------------------>|
	| | |
	| | HTTP GET SAML assn|
	| |<==================|
	| | and domain cert |
	| | |
	| | HTTP 200 OK + assn|
	| |==================>|
	| | and domain cert |
	| | |
	| | |
	| | Ringing |
	| Ringing |<------------------|
	|<------------------| |
	| | |
	| | OK |
	| OK |<------------------|
	|<------------------| |
	| | |
	| ACK | |
	|------------------>| ACK |
	| |------------------>|
	| | |
	| | |
	... many more msgs...
	Figure 8: SIP Conferencing and SAML
	However, there are obvious scaling issues with the conference server
	having to do the outbound requests in order to obtain SAML assertions
	and certificates for conference participants.
	This could be addressed by creating another SIP SAML Profile where
	the caller obtains the necessary information, e.g., SAML assertions,
	and places them into its SIP request message prior to sending it.
	This would obviate the need for the callee relying party to make
	requests in order to obtain said information. This is a topic for
	future work, and possibly future revisions of this specification.
	A.3. Compensation using SIP and SAML
	This section describes a scenario where SAML is used in SIP to
	realize compensation functionality as described in
	[I-D.jennings-sipping-pay].
	Note that this scenario is not directly addressed by the SIP SAML
	Profile and SAML SIP Binding presently defined in this specification.
	Rather, this use case calls for additional such profiles and bindings
	to be developed.
	+--------+ +--------+ +--------+
	|Payment | | User | |Merchant|
	|Provider| | Alice | |Bob |
	| | | | | |
	| | | | | |
	+---+----+ +---+----+ +---+----+
	| | |
	| | 1) Call |
	| |------------------------>|
	| | |
	| | 2) 402 + Payment Offer |
	| 3) Request for |<------------------------|
	| a Payment | |
	|<----------------------| |
	| | |
	| 4) SAML Assertion | |
	| (=Receipt) | |
	|---------------------->| |
	| | 5) Call + Receipt |
	| |------------------------>|
	| | |
	| | 6) 200 OK |
	| |<------------------------|
	| | |
	Figure 9: Message flow for SIP payment
	User Alice and the Merchant Bob interact with each other using SIP
	and the Alice uses HTTP to exchange messages with a Payment Provider.
	Initially, Alice makes a call to Bob (1). Bob determines that a
	payment is required and includes information about the payment in an
	Offer body of a 402 (Payment Required) response to Alice (2). Alice
	looks at this Offer and decides to make a payment. Alice therefore
	instructs her Payment Provider to make a transfer from Alice"s
	account to the Merchants"s account (3) using a request for a SAML
	assertion with the extensions defined in this document. The Payment
	Provider returns a receipt for this transfer (4). This receipt is a
	SAML Assertion. Alice resubmits the call to Bob but this time
	provides the Receipt for the transaction (5). Bob determines whether
	the Receipt is valid (by checking the digital signature and the
	content of the assertion) and continues with the call processing, if
	the authorization was succesful.
	The Offer contains information about the participating parties (i.e.,
	the Payment Provider, the Merchant Bob, and the user Alice), the
	transaction amount, the account identifier for Bob at the Payment
	Provider, and a replay protection indicator to make it easier for the
	Merchant Bob to avoid replay attacks. User Alice includes this
	information when making the Request for Payment to the Payment
	Provider; adds its own account information and authorization
	password; and sends this to the Payment Provider, which produces a
	Receipt for the transaction if it is successful. This transfer from
	Alice to the Payment Provider is made across an encrypted, integrity
	protected channel. The Receipt includes a timestamp when the Payment
	Provider made the transaction and protects the Receipt with a digital
	signature. Alice resubmits the call to the Merchant Bob with the
	Receipt from the Payment Provier. Merchant Bob can check for replay
	attacks using the timestamp and a replay protection indiciator
	initially provided with the Offer. Bob can then check the signature
	is valid using the Payment Provider"s public key.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
End of changes. 14 change blocks.
	235 lines changed or deleted		62 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/