One document matched: draft-hallambaker-omnipublish-00.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<rfc ipr="trust200902" docName="draft-hallambaker-sxs-confirm-01">
<front>
<title abbrev="SXS Confirmation Protocol (SXS-Confirm)">SXS Confirmation Protocol (SXS-Confirm)</title>
<author fullname="Phillip Hallam-Baker" initials="P. M." surname="Hallam-Baker">
<organization>Comodo Group Inc.</organization>
<address>
<email>philliph@comodo.com</email>
</address>
</author>
<date day="21" month="May" year="2014"/>
<area>General</area>
<workgroup/>
<keyword>Cryptography</keyword>
<keyword>PKI</keyword>
<keyword>PKIX</keyword>
<abstract>
<t>JSON Confirmation Protocol (JCP) is a three party Web Service that supports a transactional second factor confirmation mechanism that provides a superset of the capabilities of traditional second factor authentication schemes. </t>
</abstract>
</front>
<middle>
<section title="Background" anchor="Section_1">
<t>Authentication of end users is one of the biggest challenges for Internet and Web security today. Despite an abundance of technology that offers authentication mechanisms that are more robust, more secure and easier to use, the default mechanism for user authentication is the use of usernames and passwords. </t>
<t>Unlike traditional schemes, JCP is designed for implementation on a device that has at least the capabilities of a modern 'smartphone'. In particular an JCP client device must support a display, a means of accepting text input from the user and a connection to the Internet. </t>
<t>While mobile devices offering this degree of functionality were rare in 2007, they have since become ubiquitous. It is thus now a practical proposition for a site requiring second factor authentication to support at least a part of its users using a technology that requires this level of capability. Indeed software applications that emulate traditional second factor authentication protocols on such devices have been available for some time. </t>
<section title="Second Factor Authentication" anchor="Section_1_1">
<t>Second factor authentication mechanisms offer greater security over the use of passwords alone by combining a first factor (typically a password) with a biometric or proof of possession of a physical token. </t>
<t>Traditional second factor authentication techniques have suffered from the need to distribute physical tokens and the difficulty of ensuring that a biometric authentication is presented to a trustworthy terminal. </t>
<t>The usability of traditional second factor authentication techniques has been poor or worse. Even the simplest scheme in which the user is required to read in a 'one time use' numeric code from the authentication token device and enter it into a password field. While such operations are relatively simple they require the user to engage in a sequence of operations that bears no necessary or natural relationship to the underlying task for which the authentication is required. </t>
<t>Nor does the act of engaging in a traditional second factor scheme offer proof of anything other than that the user was authenticated. Any correspondence between the act of authentication and the purpose for which the authentication was provided must be maintained separately. </t>
</section>
<section title="Confirmation vs. Authentication" anchor="Section_1_2">
<t>A second factor confirmation service addresses the limitations of traditional second factor authentication schemes. </t>
<t>A confirmation service allows the user experience to be precisely matched to the action that the user is attempted. Instead of beinf asked to read a random number from one device and enter it into another, the user is asked if they really want to perform the action for which authentication is requested. </t>
<t>A confirmation service offers better accountability for end users than a traditional authentication service. An authentication service only provides an assertion that the user was present. A confirmation service provides an assertion that the user was present and that they confirmed a specific transaction. </t>
<t>For example, Alice has been granted access to a machine storing classified data. If an authentication service is used for access control, the authentication service log will only record the dates and times that Alice accessed the system. to find out if Alice accessed a particular file on a particular day it is necessary to consult and correlate both the authentication log of the system and the activity log for the application. </t>
<t>If instead a confirmation service is used the confirmation log contains an authenticated record of both the authentication events and the transactions for which the authentication was requested. </t>
</section>
<section title="Use Scenarios" anchor="Section_1_3">
<t>A confirmation service complements rather than replaces a traditional authentication scheme. Providing a highly secure and convenient means of authenticating requests that carry a high degree of risk mitigates the risk of using convenient but intrinsically low security techniques for other actions. </t>
</section>
<section title="Use in Financial Services" anchor="Section_1_4">
<t>If an attacker is to profit from breaching a an account with a financial service such as a bank or a brokerage they must find a way to move money out of the account. Thus adding bill payment recipients, initiating wire transfers and trading in low volume 'penny stocks' represent high risk activities. </t>
<t>For example: Bank of Ethel might permit customers to use a simple username and password scheme to gain access to their account for the purpose of checking their balance or paying bills to existing reciepients but require use of the second factor confirmation device for a high risk transaction such as paying a bill. </t>
</section>
<section title="Machine Binding" anchor="Section_1_5">
<t>A second factor confirmation service may be combined with a machine level authentication scheme to permit a transparent form of authentication for low risk transactions. </t>
<t>For example: Alice stores her low risk authentication credentials (e.g usernames and passwords) using a 'cloud' service. When she wishes to use those credentials an agent on her personal machine fetches credentials from the cloud service as necessary. When Alice wishes to access a site from a different machine she receives a confirmation request on her mobile device to grant access from that machine. </t>
<t>Use of such a mechanism is clearly more satisfactory when suitable cryptographic protocols such as SAML or Kerberos are employed to limit the disclosure and hence possible compromise of the credentials. The specification of such protocols is outside the scope of this document. </t>
</section>
<section title="Tethered Use" anchor="Section_1_6">
<t>Although JCP is designed for use in a three party scenario, there are situations in which a two party mode may be preferred. </t>
<t>For example: Bob is a roadwarrior who requires access to confidential documents stored on his laptop device from anywhere in the world, including locations where Internet access is not possible. To permit access in such circumstances, Bob's JCP client supports use of a tethered mode in which the mobile device is plugged into his laptop via a USB port. </t>
<t>For example: Carol is a network manager of a large computing facility that uses JCP to authenticate and track all changes to critical resources. Since JCP is itself a network resource a bootstrap consideration arises: How can Carol confirm her network configuration requests using JCP when the network itself is down? Support for a tethered mode in which the JCP device communicates via USB or similar wired protocol allows this use case to be supported. </t>
<t>While availability of a tethered mode is clearly essential if JCP is to be used in certain applications, support for this feature outside the scope of this version of the specification. </t>
</section>
<section title="Co-Browser" anchor="Section_1_7">
<t>While JCP is designed for deployment on a secondary device, deployment on the same device as the one for which confirmation is being requested is also possible and can provide security benefits. </t>
<t>Modern Web browsers are large and complex with many features such as support for mobile code that are incompatible with a high security environment. Separating the confirmation protocol from the Web Browsing protocol permits implementation in a minimal client designed to permit detailed security analysis. Such a client might be embedded in or support means of secure interaction with a trustworthy operating system component. </t>
<t>While this means of deployment does not provide a true second factor confirmation, it is likely to provide a sufficient degree of authentication for many transactions. </t>
</section>
</section>
<section title="Architecture" anchor="Section_2">
<t>JCP is a Web Service that permits a Enquirer to request that a User confirm or reject a specified action. If the user responds, the response is signed with a digital signature under a key that is unique to the user account, the client and the device. </t>
<section title="Parties" anchor="Section_2_1">
<t>Each JCP protocol interaction takes place between a connection pair of the following parties: </t>
<t><list style="hanging">
<t hangText="Initiator">A party that initiates a confirmation request. </t>
<t hangText="User">The User is the person being asked to grant or refuse confirmation. A User MAY have multiple accounts with multiple Broker Services. </t>
<t hangText="User Device">A device that the user has bound to their broker account. </t>
<t hangText="Broker">A clearing house that stores and forwards requests from Initiators to Users Device and responses from Users to Initiators. The Broker is only trusted to perform routing filtering and recording of requests and responses. The Broker is not trusted with respect to the responses returned. </t>
</list></t>
<figure>
<artwork>
<![CDATA[
+-------------+ +------------+ +-------------+
| Initiator | <-----> | Broker | <------ | Device |
+-------------+ +------------+ +-------------+
^
|
V
+-------------+
| User |
+-------------+
]]></artwork>
</figure>
</section>
<section title="Accounts" anchor="Section_2_2">
<t>Users are identified by means of an account identifier. The display presentation of an account identifier is the form of an RFC2822 email address identifier without the enclosing angle braces, for example: </t>
<t>alice@example.com </t>
<t>The account identifier is used by the User when registering the use of the confirmation service with a Broker. </t>
</section>
<section title="Open and Closed Services" anchor="Section_2_3">
<t>An JCP service MAY be Open or Closed. An Open service provider provides JCP service to the general public. A Closed service provider only provides service to a specific community. </t>
<t>For example: An Internet Service Provider or DNS Registrar might provide an open JCP service as a part of their standard service offering to customers. An employer might operate a closed JCP service to be used for company business. </t>
</section>
</section>
<section title="Protocol" anchor="Section_3">
<t>SXS-Confirm is presented in JSON encoding [RFC4627] over a HTTP Session [RFC2616] using HTTP Session Continuation [I-D.hallambaker-httpsession] for message layer authentication. Implementations MUST support and SHOULD use TLS transport for confidentiality and server authentication [RFC4627]. </t>
<t>The Session Connection Service (SXS) [I-D.hallambaker-wsconnect] is used to establish the connection between the User Device and the Broker and the Initiator and the Broker. In each case the Broker is the SXS service. The Initiator and User Device are SXS clients. </t>
<t>SXS supports mutual and server-only authentication modes. Authentication MAY be performed using a wide range of client authentication mechanisms including PIN based, Out Of Band, PKI and none. </t>
<t>For a Private broker, the choice of authentication mode and credential lifetime is left to individual site policy. </t>
<section title="User Device Service Connection" anchor="Section_3_1">
<t>Alice is a new employee of Example Inc which has the domain example.com. To make use of the connfirmation service, Alice must first configure her device for use. This would typically be performed once for the lifetime of the device. Her system administrator issues her with an account alice@example.com and a one time use PIN Q80370-1RA606-F04B.</t>
<t>Alice installs an SXS-Confirm application on her device. To configure the device she supplies the data proivided by the system administrator:</t>
<figure>
<artwork>
<![CDATA[
AccountName: alice@example.com
PIN: Q80370-1RA606-F04B
]]></artwork>
</figure>
<t>The application MAY allow Alice to enter additional passwords and/or capture biometric profile data to provide multi-factor authentication in cases in which this is required. </t>
<t>The device makes an SXS service establishment request: </t>
<figure>
<artwork>
<![CDATA[POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Host: localhost:8080
Content-Length: 348
Expect: 100-continue
{
"OpenPINRequest": {
"Encryption": ["A128CBC",
"A256CBC",
"A128GCM",
"A256GCM"],
"Authentication": ["HS256",
"HS384",
"HS512",
"HS256T128"],
"Account": "alice",
"Service": ["sxs-confirm-user"],
"Domain": "example.com",
"HaveDisplay": false,
"Challenge": "
5S8iMguqQjToLsiYkWzFqg"}}
]]></artwork>
</figure>
<t>The service verifies the request and issues a challenge to verify holdership of the PIN: </t>
<figure>
<artwork>
<![CDATA[HTTP/1.1 281 Pin code required
Content-Length: 511
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"OpenPINResponse": {
"Status": 281,
"StatusDescription": "Pin code required",
"Challenge": "
14w9zlndGuTL--MpoFvqGw",
"ChallengeResponse": "
0ZQ0sBgH2by-tsDOO1Z0ZgGs2JwbALHK8P3Xe5wV1ds",
"Cryptographic": {
"Secret": "
TXF8EFu-MEsoyYYeernfkA",
"Encryption": "A128CBC",
"Authentication": "HS256",
"Ticket": "
llSYMf2-eLXtBUI0gimo4EWh7s73dDI-CGPRH8pA1kO3jphiQ-dRy0xbuwNm2lS3
rLApBeSy43gY0Lw-hG-GwyYFEiAaBbcBd5SbEuPzmFAFvIIAJR1FWnItHWmeLqT2
uXqaZ90dCZpUVFCMSrhzXA"}}}
]]></artwork>
</figure>
<t>Having received the challenge, the client presents proof of knowledge of the PIN:</t>
<figure>
<artwork>
<![CDATA[POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=WWL9QUlubhwTCc-p3IPoj5n8lDX5fTMF0Y5IVyJ27Mk;
Id=llSYMf2-eLXtBUI0gimo4EWh7s73dDI-CGPRH8pA1kO3jphiQ-dRy0xbuwNm
2lS3rLApBeSy43gY0Lw-hG-GwyYFEiAaBbcBd5SbEuPzmFAFvIIAJR1FWnItHWm
eLqT2uXqaZ90dCZpUVFCMSrhzXA
Host: localhost:8080
Content-Length: 133
Expect: 100-continue
{
"TicketRequest": {
"Service": ["sxs-confirm-user"],
"ChallengeResponse": "
NtLC4b3Yh-M4nYE-d8L7AR20xjjCQaUoqsCJszSyJ8E"}}
]]></artwork>
</figure>
<t>The service now completes the transaction by returning the connection credentials:</t>
<figure>
<artwork>
<![CDATA[HTTP/1.1 OK Success
Content-Length: 855
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"TicketResponse": {
"Status": 200,
"StatusDescription": "Success",
"Cryptographic": [{
"Protocol": "sxs-connect",
"Secret": "
arirqsCsTxd__rS4fP3z_w",
"Encryption": "A128CBC",
"Authentication": "HS256",
"Ticket": "
SBogEm9gzuX7i0NoRI4B6Fpjn_JN1XW6WudJNSesXLSs0MmQjqpTpG9aQ7r308DE
WMsscT9ty8f4_lKNyVVVcnuTMlHUTbeKMJKLjavR7YA"}],
"Service": [{
"Service": "sxs-confirm-user",
"Name": "localhost",
"Port": 8080,
"Priority": 100,
"Weight": 100,
"Transport": "HTTP",
"Cryptographic": {
"Secret": "
cjOJoN1vQJI4fHtWqyi-Eg",
"Encryption": "A128CBC",
"Authentication": "HS256T128",
"Ticket": "
9iWlfDxGtFPS8hwVlKLHt4IDFdDj6TiJMUU8WvRTnuKTwS9pKZJLuBdRg-2Ea8Ld
m_77w3dwvYyipqTm3BUHbA-hxeBLBcJgpuXD6KdA92I"}}]}}
]]></artwork>
</figure>
<t>Note that for the sake of brevity, only a single confirmation host is specified in these examples. A service MAY specify multiple hosts to provide for service connectivity in the case of a service outage affecting only one host.</t>
</section>
<section title="Initiator Service Connection" anchor="Section_3_2">
<t>Having connected her device to the SXS-Confirm service, Alice begins work. She attempts to gain access to a restricted Web Site in the corporate Intranet. This site requires that she confirm this request using her registered User Device and that the BIOMETRIC authentication factor be used as a second factor.</t>
<t>Alice enters her account into the site. Note that she does not supply a password to the site. </t>
<figure>
<artwork>
<![CDATA[
SXSConfirm Account: alice@example.com
]]></artwork>
</figure>
<t>The Web site initiates a request for confirmation of the access request. It begins by identifying the service from Alice's account as example.com. If the Initiator has already established a connection to this broker and it has not expired, that connection is reused. Otherwise the Initiator MUST establish a connection to the Broker. This has two steps, broker discovery and the session establishment itself. </t>
<section title="Broker Discovery" anchor="Section_3_2_1">
<t>To obtain the broker for the SXSConfirm service, the SRV Service Discovery mechanism [RFC2782] and Well Known Service conventions [RFC5785] are used: </t>
<t><list style="hanging">
<t hangText="SRV Prefix:"> </t>
<t hangText="Well Known Service Identifier:"> </t>
</list></t>
<t>Initiator clients MUST support the following service discovery mechanism: </t>
<t><list style="symbols">
<t>[1] Attempt to resolve an SRV record for _sxsconfirm._tcp.<host></t>
<t>[2] If no SRV record is found a client MAY attempt to discover the service at https://<host>/.well-known/sxsconfirm/</t>
</list></t>
<t>The Initiator begins by retrieving the SRV record for example.com:</t>
<figure>
<artwork>
<![CDATA[
_sxsconfirm._tcp.example.com SRV 0 1 8080 sxsconfirm0.example.com
_sxsconfirm._tcp.example.com SRV 0 1 8080 sxsconfirm1.example.com
]]></artwork>
</figure>
<t>The service randomly selects the host sxsconfirm1. The Web Service Endpoint for the SXSConfirm service is therefore: </t>
<figure>
<artwork>
<![CDATA[https://sxsconfirm1:8080/.well-known/sxsconfirm/]]></artwork>
</figure>
</section>
<section title="Establish Service Connection to Broker" anchor="Section_3_2_2">
<t>Having determined the service endpoint, the Initiator attempts to establish a connection. Since this is a server to server interaction, TLS Certificate based Client Authentication is used in combination with the SXS BindRequest: </t>
<figure>
<artwork>
<![CDATA[POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Host: localhost:8080
Content-Length: 227
Expect: 100-continue
{
"BindRequest": {
"Service": ["sxs-confirm-initiator"],
"Encryption": ["A128CBC",
"A256CBC",
"A128GCM",
"A256GCM"],
"Authentication": ["HS256",
"HS384",
"HS512",
"HS256T128"]}}
]]></artwork>
</figure>
<figure>
<artwork>
<![CDATA[HTTP/1.1 OK Success
Content-Length: 580
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"TicketResponse": {
"Status": 200,
"StatusDescription": "Success",
"Cryptographic": [],
"Service": [{
"Service": "sxs-confirm-initiator",
"Name": "localhost",
"Port": 8080,
"Priority": 100,
"Weight": 100,
"Transport": "HTTP",
"Cryptographic": {
"Secret": "
6FOiWaEb_54Q1PMuzsmrbA",
"Encryption": "A128CBC",
"Authentication": "HS256T128",
"Ticket": "
t2lm_h3wbKVF2hzkoHXaG1Q5wMv7P03RhQgBeEsBkV_8zXYcx7GzhCSxqHpgmhGo
6CIO5vV6w3n3sEYvArSCeHFoGw59IHCuFOvBoKe9EME"}}]}}
]]></artwork>
</figure>
</section>
</section>
<section title="Query" anchor="Section_3_3">
<t>Having established a connection to the service, the Initiator can make its confirmation request: </t>
<figure>
<artwork>
<![CDATA[POST /.well-known/sxs-confirm-initiator/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=jWwsg7lWNquvAokfx4OQ414RWo_YbKITOhF3-TadxtQ;
Id=t2lm_h3wbKVF2hzkoHXaG1Q5wMv7P03RhQgBeEsBkV_8zXYcx7GzhCSxqHpg
mhGo6CIO5vV6w3n3sEYvArSCeHFoGw59IHCuFOvBoKe9EME
Host: localhost:8080
Content-Length: 904
Expect: 100-continue
{
"ConfirmationRequest": {
"Payload": "
ewogICJNZXNzYWdlSXRlbSI6IHsKICAgICJUcmFuc2FjdGlvbklEIjogIgo2VkJu
dHJwNnJmc182SlkwUW0zZ01RIiwKICAgICJJc3N1ZSI6ICIyMDE0LTA1LTIxVDE2
OjA1OjU1WiIsCiAgICAiQWNjb3VudCI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAg
ICAiVGV4dCI6ICJ7XG4gIFwiUmVxdWVzdFRleHRcIjoge1xuICAgIFwiVGl0bGVc
IjogXCJDb25maXJtIEFjY2VzcyB0byBSZXN0cmljdGVkIFNpdGVcIixcbiAgICBc
IlBcIjogW1wiVGhlIGFjY291bnQgYWxpY2VAZXhhbXBsZS5jb20gaGFzIHJlcXVl
c3RlZCBhY2Nlc3MgdG8gdGhlIGNsYXNzaWZpZWQgc2l0ZS5cIixcbiAgICAgIFwi
RG8geW91IHdpc2ggdG8gcGVybWl0IHRoaXM_XCJdLFxuICAgIFwiQnV0dG9uc1wi
OiBbe1xuICAgICAgICBcIk5hbWVcIjogXCJBY3Rpb25cIixcbiAgICAgICAgXCJW
YWx1ZVwiOiBcImFjY2VwdFwiLFxuICAgICAgICBcIlRleHRcIjogXCJBY2NlcHRc
In0sXG4gICAgICB7XG4gICAgICAgIFwiTmFtZVwiOiBcIkFjdGlvblwiLFxuICAg
ICAgICBcIlZhbHVlXCI6IFwicmVqZWN0XCIsXG4gICAgICAgIFwiVGV4dFwiOiBc
IlJlamVjdFwifV19fSIsCiAgICAiQ29udGVudFR5cGUiOiAiYXBwbGljYXRpb24v
anNvbiJ9fQ"}}
]]></artwork>
</figure>
<t>Broker Responds:</t>
<figure>
<artwork>
<![CDATA[HTTP/1.1 OK Success
Content-Length: 133
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"ConfirmationResponse": {
"Status": 200,
"StatusDescription": "Success",
"TransactionID": "
XCu4oCDocPcQKBVCdL1X2w"}}
]]></artwork>
</figure>
</section>
<section title="User Response" anchor="Section_3_4">
<t>Before she can respond to an individual message, Alice must first download her pending requests from the broker: </t>
<figure>
<artwork>
<![CDATA[POST /.well-known/sxs-confirm-user/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=hj4sW_-lf9F13F7NdG-OCv2eDQKUTjGTQAp5YoGWVSg;
Id=9iWlfDxGtFPS8hwVlKLHt4IDFdDj6TiJMUU8WvRTnuKTwS9pKZJLuBdRg-2E
a8Ldm_77w3dwvYyipqTm3BUHbA-hxeBLBcJgpuXD6KdA92I
Host: localhost:8080
Content-Length: 25
Expect: 100-continue
{
"ConfirmRequest": {}}
]]></artwork>
</figure>
<t>Broker Responds:</t>
<figure>
<artwork>
<![CDATA[HTTP/1.1 OK Success
Content-Length: 80
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"ConfirmResponse": {
"Status": 200,
"StatusDescription": "Success"}}
]]></artwork>
</figure>
<t>Alice can now confirm the request from the Web Server: </t>
<figure>
<artwork>
<![CDATA[[To Be Specified]]]></artwork>
</figure>
<t>Broker Responds:</t>
<figure>
<artwork>
<![CDATA[[To Be Specified]]]></artwork>
</figure>
</section>
<section title="Query Response" anchor="Section_3_5">
<t>The Broker can now provide the Initiator with its response: </t>
<figure>
<artwork>
<![CDATA[POST /.well-known/sxs-confirm-initiator/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=fztYuA1t_mvfRjruWX6J7f0RpI2dEgHCh2xHdXM-_XY;
Id=t2lm_h3wbKVF2hzkoHXaG1Q5wMv7P03RhQgBeEsBkV_8zXYcx7GzhCSxqHpg
mhGo6CIO5vV6w3n3sEYvArSCeHFoGw59IHCuFOvBoKe9EME
Host: localhost:8080
Content-Length: 71
Expect: 100-continue
{
"StatusRequest": {
"TransactionID": "
XCu4oCDocPcQKBVCdL1X2w"}}
]]></artwork>
</figure>
<t>Broker Responds:</t>
<figure>
<artwork>
<![CDATA[HTTP/1.1 OK Success
Content-Length: 79
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"StatusResponse": {
"Status": 200,
"StatusDescription": "Success"}}
]]></artwork>
</figure>
<t>Note that since the user might take seconds, minutes, hours or even days to respond to a request, more than one mechanism for returning the User response to the Initiator is required. These mechanisms are:</t>
<t><list style="hanging">
<t hangText="Continuing HTTP Session.">A broker MAY allow an Initiator to keep the initial HTTP session alive for a sufficiently long interval for the user to respond.</t>
<t hangText="Polling">A broker MUST support the AskStatus transaction that permits the Initiator to query the status of a pending transaction. This mechanism permits a Broker to set a minimum interval within which a status update request will be responded to and refuse queries that are too frequent.</t>
<t hangText="Asynchronous">An Initiator MAY specify a URI being the Web Service Endpoint of a Web Service to which the Broker may return the user response using the AsyncStatus transaction. </t>
</list></t>
<t>The UYFM transport permits low latency status reports to be made with minimal server resource use. </t>
</section>
</section>
<section title="Binding" anchor="Section_4">
<t>Uses SXS with the Protocol type SXS-CONFIRM for device binding</t>
</section>
<section title="ConfirmationBroker" anchor="Section_5">
<section title="ConfirmationBroker Transactions" anchor="Section_5_1">
</section>
<section title="ConfirmationBroker Messages" anchor="Section_5_2">
</section>
<section title="ConfirmationBroker Structures" anchor="Section_5_3">
<section title="Structure: MessageItem" anchor="Section_5_3_1">
<t>A request </t>
<t><list style="hanging">
<t hangText="TransactionID :">Binary [1..1] Unique Message Identifier assigned by either the Initiator or broker. Note that unlike an email message identifier, the transaction identifier SHOULD change. </t>
<t hangText="Issue :">DateTime [1..1] Time at which the transaction identifier was issued </t>
<t hangText="Entry :">DateTime [0..1] Time at which the request was initiated if different from the Issue time. </t>
<t hangText="Account :">String [1..1] The account to which the request was directed. A given user MAY have multiple accounts and multiple users MAY have authority to respond to a given account. </t>
<t hangText="Text :">String [1..1] Text describing the request to the user. </t>
<t hangText="ContentType :">String [0..1] Format of the request text. </t>
<t hangText="Factor :">String [0..Many] Keyword indicating that a particular multi-factor authentication technique is required. </t>
</list></t>
</section>
<section title="Structure: RequestText" anchor="Section_5_3_2">
<t><list style="hanging">
<t hangText="Title :">String [0..1] Title of the request message </t>
<t hangText="P :">String [0..Many] Paragraph of request message text </t>
<t hangText="Buttons :">Input [0..Many] Button Entry </t>
</list></t>
</section>
<section title="Structure: Input" anchor="Section_5_3_3">
<t><list style="hanging">
<t hangText="Name :">String [0..1] Specifies a JSON tag name to be specified if the button is pressed to make the response. </t>
<t hangText="Value :">String [0..1] Specifies a string of text to be returned as the value of the 'Name' tag. </t>
<t hangText="Text :">String [0..1] Text to be displayed to the user </t>
</list></t>
</section>
</section>
</section>
<section title="ConfirmationBroker" anchor="Section_6">
<section title="ConfirmationBroker Transactions" anchor="Section_6_1">
<section title="Confirmation" anchor="Section_6_1_1">
<t><list style="symbols">
<t>Request: ConfirmationRequest</t>
<t>Response: ConfirmationResponse</t>
</list></t>
<t>Post a request for confirmation to a user. </t>
</section>
<section title="AskStatus" anchor="Section_6_1_2">
<t><list style="symbols">
<t>Request: StatusRequest</t>
<t>Response: StatusResponse</t>
</list></t>
<t>Query the status of a pending Confirmation transaction </t>
<t>Note that the status values only report the success or failure of the transaction itself. User responses are only returned as signed content. </t>
</section>
<section title="Cancel" anchor="Section_6_1_3">
<t><list style="symbols">
<t>Request: CancelRequest</t>
<t>Response: InitiatorResponse</t>
</list></t>
</section>
<section title="AsyncStatus" anchor="Section_6_1_4">
<t><list style="symbols">
<t>Request: PresentStatus</t>
<t>Response: TransactionResponse</t>
</list></t>
<t>Asynchronous status update on pending transaction. </t>
</section>
</section>
<section title="ConfirmationBroker Messages" anchor="Section_6_2">
<section title="Message: InitiatorRequest" anchor="Section_6_2_1">
</section>
<section title="Message: InitiatorResponse" anchor="Section_6_2_2">
<t><list style="hanging">
<t hangText="Status :">Integer [1..1] Status return code value </t>
<t hangText="StatusDescription :">String [0..1] Describes the status code (ignored by processors) </t>
</list></t>
</section>
<section title="Message: ConfirmationRequest" anchor="Section_6_2_3">
<t>Request a confirmation from a specified user. </t>
<t><list style="hanging">
<t hangText="Header :">Binary [0..1] If present specifies a Jose Web Signature Protected Header. </t>
<t hangText="Payload :">Binary [1..1] A Base64 encoded binary field, the contents of which are a MessageItem structure. </t>
<t hangText="Signature :">Binary [0..1] If present specifies a Jose Web Signature Value. </t>
<t hangText="ReplyTo :">URI [0..1] URI of a web service to which the service MAY post an asynchronous reply using the TransactionStatus transaction. </t>
</list></t>
</section>
<section title="Message: ConfirmationResponse" anchor="Section_6_2_4">
<t><list style="hanging">
<t hangText="Status :">Integer [1..1] Status return code value </t>
<t hangText="StatusDescription :">String [0..1] Describes the status code (ignored by processors) </t>
<t hangText="TransactionID :">Binary [1..1] Unique Transaction Identifier for us in subsequent StatusRequest messages. </t>
</list></t>
</section>
<section title="Message: StatusRequest" anchor="Section_6_2_5">
<t><list style="hanging">
<t hangText="TransactionID :">Binary [1..1] Unique Transaction Identifier returned in ConfirmationResponse message </t>
</list></t>
</section>
<section title="Message: StatusResponse" anchor="Section_6_2_6">
<t><list style="hanging">
<t hangText="Status :">Integer [1..1] Status return code value </t>
<t hangText="StatusDescription :">String [0..1] Describes the status code (ignored by processors) </t>
<t hangText="UserResponse :">String [1..1] Confirmation response from the user as specified by the confirmation challenge text. </t>
</list></t>
</section>
<section title="Message: PresentStatus" anchor="Section_6_2_7">
<t><list style="hanging">
<t hangText="UserResponse :">String [1..1] Confirmation response from the user as specified by the confirmation challenge text. </t>
</list></t>
</section>
<section title="Message: CancelRequest" anchor="Section_6_2_8">
<t><list style="hanging">
<t hangText="TransactionID :">Binary [1..1] [TBS]</t>
</list></t>
</section>
</section>
<section title="ConfirmationBroker Structures" anchor="Section_6_3">
</section>
</section>
<section title="ConfirmationBroker" anchor="Section_7">
<section title="ConfirmationBroker Transactions" anchor="Section_7_1">
<section title="GetMessages" anchor="Section_7_1_1">
<t><list style="symbols">
<t>Request: GetMessagesRequest</t>
<t>Response: GetMessagesResponse</t>
</list></t>
</section>
<section title="Confirm" anchor="Section_7_1_2">
<t><list style="symbols">
<t>Request: ConfirmRequest</t>
<t>Response: ConfirmResponse</t>
</list></t>
</section>
</section>
<section title="ConfirmationBroker Messages" anchor="Section_7_2">
<section title="Message: GetMessagesRequest" anchor="Section_7_2_1">
<t/>
<t><list style="hanging">
<t hangText="OnOrAfter :">DateTime [0..1] </t>
<t hangText="Before :">DateTime [0..1] </t>
<t hangText="MaxLength :">Integer [0..1] Maximum request text length in bytes </t>
</list></t>
</section>
<section title="Message: GetMessagesResponse" anchor="Section_7_2_2">
<t/>
<t><list style="hanging">
<t hangText="Status :">Integer [1..1] Status return code value </t>
<t hangText="StatusDescription :">String [0..1] Describes the status code (ignored by processors) </t>
<t hangText="Pending :">Integer [1..1] Number of pending confirmation requests. </t>
<t hangText="Answered :">Integer [0..1] Number of previously answered confirmation requests. </t>
<t hangText="Expired :">Integer [0..1] Number of pending confirmation requests that expired before they were answered. </t>
<t hangText="Messages :">WrappedData [1..Many] List of WrappedData objects in which the Payload field is a pending message. These MAY be returned in any order. Note that the list of messages MAY be incomplete as transactions MAY have been responded to earlier. </t>
</list></t>
</section>
<section title="Message: ConfirmRequest" anchor="Section_7_2_3">
<t/>
<t><list style="hanging">
<t hangText="UserResponse :">WrappedData [0..1] A WrappedData object whose payload is the response from the user. This is a JSON object whose tags and values are determined by the request markup. </t>
<t hangText="Abuse :">String [0..1] If present, the user has indicated that the request is being refused as abusive. For example, the message text is an unsolicited commercial message. </t>
</list></t>
</section>
<section title="Message: ConfirmResponse" anchor="Section_7_2_4">
<t>Reports the success or failure of the message </t>
<t><list style="hanging">
<t hangText="Status :">Integer [1..1] Status return code value </t>
<t hangText="StatusDescription :">String [0..1] Describes the status code (ignored by processors) </t>
</list></t>
</section>
</section>
<section title="ConfirmationBroker Structures" anchor="Section_7_3">
<section title="Structure: WrappedData" anchor="Section_7_3_1">
<t>The WrappedData object permits optional authetication data to be added to SXS-Confirm requests and responses. </t>
<t><list style="hanging">
<t hangText="Header :">Binary [0..1] If present specifies a Jose Web Signature Protected Header. </t>
<t hangText="Payload :">Binary [1..1] The signed data </t>
<t hangText="Signature :">Binary [0..1] If present specifies a Jose Web Signature Value over the header and payload values. </t>
</list></t>
</section>
</section>
</section>
<section title="Simple Request Markup Language (SRMLv1)" anchor="Section_8">
<t>While JSON markup is sufficient to send the simplest request messages, the limitations of using a data encoding format for what is essentially a document markup are apparent. </t>
<t>Simple Request Markup Language (SRML) is a markup language for use in confirmation requests. The capabilities of the basic JSON encoding are provided by the following tags:</t>
<t><list style="hanging">
<t hangText="<h1>Heading Text</h1>">Heading</t>
<t hangText="<p>Running text</p>">Paragraph</t>
<t hangText="<button value="value">User option</button>">Button specifying a value that the user can select.</t>
</list></t>
<t>While SRML is loosely based on the HTML forms markup, there are important differences. The HTML markup model supports multiple document types of which forms are only one and a single document may contain multiple forms with multiple different action values. In an SRML document is a single form and the form action to be performed is impicit in the presentation of the document to the user.</t>
<section title="XML Schema and Content Type Identifier" anchor="Section_8_1">
<t>The MIME Content Type and schema identifier for SRML are</t>
<figure>
<artwork>
<![CDATA[
Content-Type: text/xml
xmlns: http://hallambaker.com/Schemas/srml.xsd]]></artwork>
</figure>
<t>The schema is </t>
<figure>
<artwork>
<![CDATA[<?xml version="1.0" encoding="utf-8"?>
<xs:schema id="XMLSchema1"
targetNamespace="http://hallambaker.com/Schemas/srml.xsd"
xmlns="http://hallambaker.com/Schemas/srml.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="srml" type="SRMLType"/>
<xs:complexType name="SRMLType">
<xs:sequence>
<xs:element name="title" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<xs:element name="p" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="button" minOccurs="2" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="button" type="InputType"/>
<xs:complexType name="InputType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name" type="xs:ID"/>
<xs:attribute name="value" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
]]></artwork>
</figure>
</section>
<section title="Design considerations and future options" anchor="Section_8_2">
<t>The capabilities of SRML are intentionally limited to the bare minimum. It should be possible to make use of SRML to display options to the user on a smartwatch or other device with a highly constrained display. </t>
<t>The function of the confirmation service is to provide confirmation of an action that was initiated elsewhere. It is therefore inappropriate for this or any future version of SRML to offer extensive data entry or validation capabilities. SRML applications MUST NOT support any form of scripting or active code extensions to SRML content.</t>
<t>It might prove advantageous in the future to extend the input types to include simple form elements such as checkboxes, numeric fields, text choices and possibly free form text.</t>
</section>
</section>
<section title="Security Considerations" anchor="Section_9">
<t>Consider spam control, how do users prevent unwanted requests? (EV accreditatio, filtering at Broker) </t>
<t>People deploying JCP as a means of controlling access to networking infrastructure must consider the bootstrap issue. In particular since JCP requires Internet access the network administrator must ensure that it is possible to manage the network resources necessary to support an SXS service when that service is down. </t>
</section>
<section title="Acnowledgementsts" anchor="Section_10">
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="I-D.hallambaker-wsconnect">
<front>
<title>JSON Service Connect (JCX) Protocol</title>
<author fullname="Phillip Hallam-Baker" initials="P" surname="Hallam-Baker">
<organization/>
<address>
</address>
</author>
<date day="21" month="January" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-wsconnect-05"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-hallambaker-wsconnect-05.txt"/>
<format type="PDF" target="http://www.ietf.org/internet-drafts/draft-hallambaker-wsconnect-05.pdf"/>
</reference>
<reference anchor="RFC2782">
<front>
<title>A DNS RR for specifying the location of services (DNS SRV)</title>
<author fullname="Arnt Gulbrandsen" initials="A." surname="Gulbrandsen">
<organization>Troll Tech</organization>
<address>
</address>
</author>
<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Internet Software Consortium</organization>
<address>
</address>
</author>
<author fullname="Levon Esibov" initials="L." surname="Esibov">
<organization>Microsoft Corporation</organization>
<address>
</address>
</author>
<date month="February" year="2000"/>
</front>
<seriesInfo name="RFC" value="2782"/>
<format type="TXT" target="http://www.rfc-editor.org/rfc/rfc2782.txt" octets="24013"/>
</reference>
<reference anchor="RFC5785">
<front>
<title>Defining Well-Known Uniform Resource Identifiers (URIs)</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
<address>
</address>
</author>
<author fullname="E. Hammer-Lahav" initials="E." surname="Hammer-Lahav">
<organization/>
<address>
</address>
</author>
<date month="April" year="2010"/>
</front>
<seriesInfo name="RFC" value="5785"/>
<format type="TXT" target="http://www.rfc-editor.org/rfc/rfc5785.txt" octets="13779"/>
</reference>
<reference anchor="RFC4627">
<front>
<title>The application/json Media Type for JavaScript Object Notation (JSON)</title>
<author fullname="D. Crockford" initials="D." surname="Crockford">
<organization/>
<address>
</address>
</author>
<date month="July" year="2006"/>
</front>
<seriesInfo name="RFC" value="4627"/>
<format type="TXT" target="http://www.rfc-editor.org/rfc/rfc4627.txt" octets="16319"/>
</reference>
<reference anchor="RFC2616">
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author fullname="Roy T. Fielding" initials="R." surname="Fielding">
<organization>Department of Information and Computer Science</organization>
<address>
</address>
</author>
<author fullname="James Gettys" initials="J." surname="Gettys">
<organization>World Wide Web Consortium</organization>
<address>
</address>
</author>
<author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul">
<organization>Compaq Computer Corporation</organization>
<address>
</address>
</author>
<author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk">
<organization>World Wide Web Consortium</organization>
<address>
</address>
</author>
<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox Corporation</organization>
<address>
</address>
</author>
<author fullname="Paul J. Leach" initials="P." surname="Leach">
<organization>Microsoft Corporation</organization>
<address>
</address>
</author>
<author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee">
<organization>World Wide Web Consortium</organization>
<address>
</address>
</author>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2616"/>
<format type="TXT" target="http://www.rfc-editor.org/rfc/rfc2616.txt" octets="422317"/>
<format type="PS" target="http://www.rfc-editor.org/rfc/rfc2616.ps" octets="5529857"/>
<format type="PDF" target="http://www.rfc-editor.org/rfc/rfc2616.pdf" octets="550558"/>
<format type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2616.html" octets="637302"/>
<format type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2616.xml" octets="493420"/>
</reference>
<reference anchor="I-D.hallambaker-httpsession">
<front>
<title>HTTP Session Management</title>
<author fullname="Phillip Hallam-Baker" initials="P" surname="Hallam-Baker">
<organization/>
<address>
</address>
</author>
<date day="21" month="January" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-httpsession-02"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-hallambaker-httpsession-02.txt"/>
<format type="PDF" target="http://www.ietf.org/internet-drafts/draft-hallambaker-httpsession-02.pdf"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 14:35:55 |