Network Working Group P. Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended status: Informational May 10, 2017
Expires: November 11, 2017
Mesh Confirmation Protocol (Mesh/Confirm)
draft-hallambaker-mesh-confirm-00
Abstract
Mesh Confirmation Protocol (Mesh/Confirm) 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. The three parties in the
protocol are Enquirer who posts a confirmation request, a Responder
who may or may not respond to the request and the Broker where the
requests and responses are posted.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 11, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Hallam-Baker Expires November 11, 2017 [Page 1]
Internet-Draft Mesh/Confirm May 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Second Factor Authentication . . . . . . . . . . . . . . 3
1.2. Confirmation vs. Authentication . . . . . . . . . . . . . 4
1.3. Use Scenarios . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Use in Financial Services . . . . . . . . . . . . . . . . 5
1.5. Machine Binding . . . . . . . . . . . . . . . . . . . . . 5
1.6. Tethered Use . . . . . . . . . . . . . . . . . . . . . . 5
1.7. Co-Browser . . . . . . . . . . . . . . . . . . . . . . . 6
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Accounts . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Open and Closed Services . . . . . . . . . . . . . . . . 8
2.4. Check service connection . . . . . . . . . . . . . . . . 8
2.5. Enquirer posts request. . . . . . . . . . . . . . . . . . 9
2.6. Responder fetches pending requests. . . . . . . . . . . . 10
2.7. Responder replies to request. . . . . . . . . . . . . . . 10
2.8. Enquirer fetches result . . . . . . . . . . . . . . . . . 11
3. Mesh/Confirm Service . . . . . . . . . . . . . . . . . . . . 12
3.1. Request Messages . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Message: ConfirmRequest . . . . . . . . . . . . . . . 12
3.2. Response Messages . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Message: ConfirmResponse . . . . . . . . . . . . . . 12
3.2.2. Successful Response Codes . . . . . . . . . . . . . . 13
3.2.3. Warning Response Codes . . . . . . . . . . . . . . . 13
3.2.4. Error Response Codes . . . . . . . . . . . . . . . . 14
3.2.5. Failure Response Codes . . . . . . . . . . . . . . . 14
3.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 15
3.4. Common classes . . . . . . . . . . . . . . . . . . . . . 15
3.4.1. Structure: Version . . . . . . . . . . . . . . . . . 15
3.4.2. Structure: Encoding . . . . . . . . . . . . . . . . . 16
3.5. Utility Transactions . . . . . . . . . . . . . . . . . . 16
3.6. Transaction: Hello . . . . . . . . . . . . . . . . . . . 16
3.6.1. Message: HelloRequest . . . . . . . . . . . . . . . . 16
3.6.2. Message: HelloResponse . . . . . . . . . . . . . . . 16
3.7. Enquirer Transactions . . . . . . . . . . . . . . . . . . 17
3.8. Transaction: Enquire . . . . . . . . . . . . . . . . . . 17
3.8.1. Message: EnquireRequest . . . . . . . . . . . . . . . 17
3.8.2. Message: EnquireResponse . . . . . . . . . . . . . . 18
3.9. Transaction: Status . . . . . . . . . . . . . . . . . . . 18
3.9.1. Message: StatusRequest . . . . . . . . . . . . . . . 18
3.9.2. Message: StatusResponse . . . . . . . . . . . . . . . 19
3.10. Responder Transactions . . . . . . . . . . . . . . . . . 19
3.11. Transaction: Pending . . . . . . . . . . . . . . . . . . 19
Hallam-Baker Expires November 11, 2017 [Page 2]
Internet-Draft Mesh/Confirm May 2017
3.11.1. Message: PendingRequest . . . . . . . . . . . . . . 20
3.11.2. Message: PendingResponse . . . . . . . . . . . . . . 20
3.11.3. Structure: RequestEntry . . . . . . . . . . . . . . 21
3.12. Transaction: Respond . . . . . . . . . . . . . . . . . . 21
3.12.1. Message: RespondRequest . . . . . . . . . . . . . . 22
3.12.2. Message: RespondResponse . . . . . . . . . . . . . . 22
4. Simple Request Markup Language (SRMLv1) . . . . . . . . . . . 22
5. Heading Text . . . . . . . . . . . . . . . . . . . . . . 22
5.1. XML Schema and Content Type Identifier . . . . . . . . . 23
5.2. Design considerations and future options . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Background
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.
Unlike traditional schemes, Mesh/Confirm is designed for
implementation on a device that has at least the capabilities of a
modern 'smartphone'. In particular, a Mesh/Confirm client device
must support a display, a means of accepting text input from the user
and a connection to the Internet.
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. Software
applications that emulate traditional second factor authentication
protocols on such devices have been available for some time.
1.1. Second Factor Authentication
Second factor authentication mechanisms offer greater security over
the use of passwords alone by combining a first factor (typically a
password) with a second factor, typically a biometric or proof of
possession of a physical token.
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.
Hallam-Baker Expires November 11, 2017 [Page 3]
Internet-Draft Mesh/Confirm May 2017
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.
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.
1.2. Confirmation vs. Authentication
A second factor confirmation service addresses the limitations of
traditional second factor authentication schemes.
A confirmation service allows the user experience to be precisely
matched to the action that the user is attempted. This is simpler
and more secure. Instead of being 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.
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.
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.
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.
Hallam-Baker Expires November 11, 2017 [Page 4]
Internet-Draft Mesh/Confirm May 2017
1.3. Use Scenarios
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.
1.4. Use in Financial Services
If an attacker is to profit from breaching 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.
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
recipients but require use of the second factor confirmation device
for a high-risk transaction such as paying a bill.
1.5. Machine Binding
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.
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.
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.
1.6. Tethered Use
Although Mesh/Confirm is designed for use in a three-party scenario,
there are situations in which a two party mode may be preferred.
Hallam-Baker Expires November 11, 2017 [Page 5]
Internet-Draft Mesh/Confirm May 2017
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 Mesh/Confirm client supports use
of a tethered mode in which the mobile device is plugged into his
laptop via a USB port.
For example: Carol is a network manager of a large computing facility
that uses Mesh/Confirm to authenticate and track all changes to
critical resources. Since Mesh/Confirm is itself a network resource
a bootstrap consideration arises: How can Carol confirm her network
configuration requests using Mesh/Confirm when the network itself is
down? Support for a tethered mode in which the Mesh/Confirm device
communicates via USB or similar wired protocol allows this use case
to be supported.
While availability of a tethered mode is clearly essential if Mesh/
Confirm is to be used in certain applications, support for this
feature outside the scope of this version of the specification.
1.7. Co-Browser
While Mesh/Confirm 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.
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.
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.
2. Architecture
Mesh/Confirm 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.
Hallam-Baker Expires November 11, 2017 [Page 6]
Internet-Draft Mesh/Confirm May 2017
2.1. Parties
Each Mesh/Confirm protocol interaction takes place between a
connection pair of the following parties:
Enquirer
A party that initiates a confirmation request.
User
The User is the person being asked to grant or refuse confirmation.
A User MAY have multiple accounts with multiple Broker Services.
User Device
A device that the user has bound to their broker account.
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.
The communication between the parties is shown in Figure 1.
+-------------+ +------------+ +-------------+
| Enquirer | <-----> | Broker | <------ | Device |
+-------------+ +------------+ +-------------+
^
|
V
+-------------+
| User |
+-------------+
Figure 1. Mesh/Confirm Parties
2.2. Accounts
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:
alice@example.com
Hallam-Baker Expires November 11, 2017 [Page 7]
Internet-Draft Mesh/Confirm May 2017
The account identifier is used by the User when registering the use
of the confirmation service with a Broker.
2.3. Open and Closed Services
An Mesh/Confirm service MAY be Open or Closed. An Open service
provider provides Mesh/Confirm service to the general public. A
Closed service provider only provides service to a specific
community.
For example: An Internet Service Provider or DNS Registrar might
provide an open Mesh/Confirm service as a part of their standard
service offering to customers. An employer might operate a closed
Mesh/Confirm service to be used for company business.
2.4. Check service connection
It is often useful to be able to verify that a service is ready and
willing to perform transactions before attempting to perform one.
Especially so when the transaction requires considerable amounts of
data and may require the use of specific server determined
authentication options.
The request message is 'HelloRequest' and has no parameters:
POST /.well-known/confirm/HTTP/1.1
Host: prismproof.org
Content-Length: 23
{
"HelloRequest": {}}
The response message specifies the protocol version(s) supported, the
corresponding encodings and bindings:
HTTP/1.1 200 OK
Date: Thu 11 May 2017 03:12:20
Content-Length: 157
{
"HelloResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully",
"Version": {
"Major": 0,
"Minor": 1}}}
Hallam-Baker Expires November 11, 2017 [Page 8]
Internet-Draft Mesh/Confirm May 2017
2.5. Enquirer posts request.
Alice attempts to log into her computer system as administrator. The
site policy requires that all administrative logins be confirmed via
Mesh/Confirm. Alice's confirmation account is alice@example.com. In
this exchange, the computer Alice is trying to access is the
Enquirer, the device she uses to respond to the query (her watch) is
the Responder and the Mesh/Confirm service at example.com is the
broker.
The computer acting as Enquirer (example.net) creates a confirmation
request as follows:
Grant Administrator
Host: example.net
Note that it is not necessary to specify the reject option since this
is implicit.
The request message is 'EnquireRequest' which contains an object
signed by the Enquirer that specifies the account the request is
directed to and the request text.
POST /.well-known/confirm/HTTP/1.1
Host: prismproof.org
Content-Length: 25
{
"EnquireRequest": {}}
The request is accepted and a success response returned specifying
the transaction ID.
HTTP/1.1 200 OK
Date: Thu 11 May 2017 03:12:20
Content-Length: 105
{
"EnquireResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully"}}
Hallam-Baker Expires November 11, 2017 [Page 9]
Internet-Draft Mesh/Confirm May 2017
Note that while the requirement that request messages be
authenticated by means of a digital signature is within the scope of
Mesh/Recrypt, the specification of the filtering rules is not.
2.6. Responder fetches pending requests.
At present, the only mechanism for determining if there are pending
requests is by polling. Provision of a push notification mechanism
is an obvious priority for future improvement of the protocol.
Alice's watch regularly polls the broker to determine if there are
pending confirmation requests.
POST /.well-known/confirm/HTTP/1.1
Host: prismproof.org
Content-Length: 25
{
"PendingRequest": {}}
The response message contains the number of pending requests meeting
the selection criteria and the returned requests.
HTTP/1.1 200 OK
Date: Thu 11 May 2017 03:12:20
Content-Length: 105
{
"PendingResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully"}}
Each request is signed by the Enquirer that originally generated it.
2.7. Responder replies to request.
Alice selects the pending access request and grants herself access to
the machine she is attempting to log in to. Her watch creates a
signed response message containing the digest of the original request
and her response "Accept".
POST /.well-known/confirm/HTTP/1.1
Host: prismproof.org
Content-Length: 25
{
"RespondRequest": {}}
Hallam-Baker Expires November 11, 2017 [Page 10]
Internet-Draft Mesh/Confirm May 2017
The response message tells Alice that the transaction completed
successfully and the broker has her acceptance message.
HTTP/1.1 200 OK
Date: Thu 11 May 2017 03:12:20
Content-Length: 105
{
"RespondResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully"}}
Note that in future versions of the protocol it may be desirable to
make use of additional affordances of the device such as the ability
to perform biometric capture such as fingerprint or facial
recognition.
Another possibility is that the user might be asked to enter a one
time use PIN generated by the Enquirer, thus verifying that the user
is indeed responding to the confirmation request they believe they
are responding to.
2.8. Enquirer fetches result
The enquirer obtains the result of the confirmation request by
polling using the Status transaction.
POST /.well-known/confirm/HTTP/1.1
Host: prismproof.org
Content-Length: 24
{
"StatusRequest": {}}
Since Alice has responded, the response message contains the signed
result:
HTTP/1.1 200 OK
Date: Thu 11 May 2017 03:12:20
Content-Length: 104
{
"StatusResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully"}}
Hallam-Baker Expires November 11, 2017 [Page 11]
Internet-Draft Mesh/Confirm May 2017
As with the use of polling on the user side, it is obviously
desirable to eliminate the need for polling by introducing a callback
registration mechanism.
3. Mesh/Confirm Service
The Mesh/Confirm confirmation service is a two party protocol. An
Enquirer requests a response from the
SRV Prefix:
_Confirm._tcp
HTTP Well Known Service Prefix:
/.well-known/confirm
Every Confirm Service transaction consists of exactly one request
followed by exactly one response.
There is no set sequence in which operations are required to be
performed. It is not necessary to perform a Hello transaction prior
to a CreateGroup, AddMember or any other transaction.
3.1. Request Messages
3.1.1. Message: ConfirmRequest
Base class for all request messages.
Portal: String (Optional)
Name of the Mesh/Recrypt administration Service to which the
request is directed.
3.2. Response Messages
3.2.1. Message: ConfirmResponse
Base class for all response messages. Contains only the status code
and status description fields.
Hallam-Baker Expires November 11, 2017 [Page 12]
Internet-Draft Mesh/Confirm May 2017
A service MAY return either the response message specified for that
transaction or any parent of that message. Thus the RecryptResponse
message MAY be returned in response to any request.
Status: Integer (Optional)
Status return code. The SMTP/HTTP scheme of 2xx = Success, 3xx =
incomplete, 4xx = failure is followed.
StatusDescription: String (Optional)
Text description of the status return code for debugging and log
file use.
3.2.2. Successful Response Codes
The following response codes are returned when a transaction has
completed successfully.
[201] SuccessOK
Operation completed successfully
[201] SuccessCreated
Operation completed successfully, new data item created
[202] SuccessUpdated
Operation completed successfully, data item was updated
3.2.3. Warning Response Codes
The following response codes are returned when a transaction did not
complete because the target service has been redirected.
In the case that a redirect code is returned, the StatusDescription
field contains the URI of the new service. Note however that the
Hallam-Baker Expires November 11, 2017 [Page 13]
Internet-Draft Mesh/Confirm May 2017
redirect location indicated in a status response might be incorrect
or even malicious and cannot be considered trustworthy without
appropriate authentication.
[303] RedirectPermanent
Service has been permanently moved
[307] RedirectTemporary
Service has been temporarily moved
3.2.4. Error Response Codes
A response code in the range 400-499 is returned when the service was
able to process the transaction but the transaction resulted in an
error.
[401] ClientUnauthorized
Client is not authorized to perform specified request
[404] NotFound
The requested object could not be found.
[409] AlreadyExists
The requested object already exists.
3.2.5. Failure Response Codes
A response code in the range 500-599 is returned when the service was
unable to process the transaction but the transaction due to an
internal failure.
[500] ServerInternal
Hallam-Baker Expires November 11, 2017 [Page 14]
Internet-Draft Mesh/Confirm May 2017
An internal error occurred at the server
[503] ServerOverload
The server cannot handle the request as it is overloaded
3.3. Imported Objects
The Recrypt Administration Sercice makes use of JSON objects defined
in the JOSE Signatgure and Encryption specifications.
3.4. Common classes
The following classes are referenced at multiple points in the
protocol.
3.4.1. Structure: Version
Describes a protocol version.
Major: Integer (Optional)
Major version number of the service protocol. A higher
Minor: Integer (Optional)
Minor version number of the service protocol.
Encodings: Encoding [0..Many]
Enumerates alternative encodings (e.g. ASN.1, XML, JSON-B)
supported by the service. If no encodings are specified, the JSON
encoding is assumed.
URI: String [0..Many]
The preferred URI for this service. This MAY be used to effect a
redirect in the case that a service moves.
Hallam-Baker Expires November 11, 2017 [Page 15]
Internet-Draft Mesh/Confirm May 2017
3.4.2. Structure: Encoding
Describes a message content encoding.
ID: String [0..Many]
The IANA encoding name
Dictionary: String [0..Many]
For encodings that employ a named dictionary for tag or data
compression, the name of the dictionary as defined by that
encoding scheme.
3.5. Utility Transactions
3.6. Transaction: Hello
Request: HelloRequest
Response:HelloResponse
Report service and version information.
The Hello transaction provides a means of determining which protocol
versions, message encodings and transport protocols are supported by
the service.
3.6.1. Message: HelloRequest
o
* Inherits: ConfirmRequest
Request service description.
[None]
3.6.2. Message: HelloResponse
o
* Inherits: ConfirmResponse
Hallam-Baker Expires November 11, 2017 [Page 16]
Internet-Draft Mesh/Confirm May 2017
Always reports success. Describes the configuration of the service.
Version: Version (Optional)
Enumerates the protocol versions supported
Alternates: Version [0..Many]
Enumerates alternate protocol version(s) supported
3.7. Enquirer Transactions
3.8. Transaction: Enquire
Request: EnquireRequest
Response:EnquireResponse
Post a confirmation request to the broker.
3.8.1. Message: EnquireRequest
o
* Inherits: ConfirmRequest
Request: JoseWebEncryption (Optional)
Signed and optionally encrypted request message.
Responder: String (Optional)
The Responder account the request is directed to.
Expire: DateTime (Optional)
Hallam-Baker Expires November 11, 2017 [Page 17]
Internet-Draft Mesh/Confirm May 2017
Date and time after which the Enquirer has no interest in the
request value. Note that a Broker MAY cancel requests according
to its own policy at any time.
EnquirerID: String (Optional)
A unique identifier for the transaction generated by the enquirer.
This identifier MAY be used to reject duplicate transactions by
a broker or Requestor.
3.8.2. Message: EnquireResponse
o
* Inherits: ConfirmResponse
Reports the success or failure of an Enquire transaction.
BrokerID: String (Optional)
A unique identifier for the transaction generated by the broker.
3.9. Transaction: Status
Request: StatusRequest
Response:StatusResponse
Request status on a previously posted request
3.9.1. Message: StatusRequest
o
* Inherits: ConfirmRequest
Reports the status or of an Enquire transaction.
Cancel: Boolean (Optional)
Hallam-Baker Expires November 11, 2017 [Page 18]
Internet-Draft Mesh/Confirm May 2017
If true, the broker is abandoning the request and it should no
longer be returned to the user as an active pending request. This
flag would typically be set true on the last polling attempt made
before the Enquirer abandonds the request. It is therefore
entirely valid for a broker to return a Response value if the
Cancel flag is true.
BrokerID: String (Optional)
The unique identifier for the transaction generated by the broker
and returned in the corresponding Enquire transaction.
3.9.2. Message: StatusResponse
o
* Inherits: ConfirmResponse
The result of a status request.
RequestStatus: String (Optional)
The status value. Valid values are PENDING, BCANCEL, ECANCEL,
REPLY, REFUSED
Response: JoseWebEncryption (Optional)
Signed and optionally encrypted response message.
3.10. Responder Transactions
3.11. Transaction: Pending
Request: PendingRequest
Response:PendingResponse
Request a list of pending transactions meeting the specified
selection criteria.
Hallam-Baker Expires November 11, 2017 [Page 19]
Internet-Draft Mesh/Confirm May 2017
3.11.1. Message: PendingRequest
o
* Inherits: ConfirmRequest
Request a list of pending requests for a specified account.
Responder: String (Optional)
The Responder account the the list of pending requests is
requested for.
MaxResponse: Integer (Optional)
The maximum number of request entries to return.
BeforeId: String (Optional)
Only send request entries posted prior to the specified entry.
AfterId: String (Optional)
Only send request entries posted after the specified entry.
3.11.2. Message: PendingResponse
o
* Inherits: ConfirmResponse
Contains a list of pending requests.
Entries: RequestEntry (Optional)
List of pending requests.
Hallam-Baker Expires November 11, 2017 [Page 20]
Internet-Draft Mesh/Confirm May 2017
3.11.3. Structure: RequestEntry
Describes a pending request and associated information.
Request: JoseWebEncryption (Optional)
Signed and optionally encrypted request message.
Responder: String (Optional)
The Responder account the request is directed to.
Expire: DateTime (Optional)
Date and time after which the Enquirer has no interest in the
request value. Note that a Broker MAY cancel requests according
to its own policy at any time.
EnquirerID: String (Optional)
A unique identifier for the transaction generated by the enquirer.
This identifier MAY be used to reject duplicate transactions by
a broker or Requestor.
BrokerID: String (Optional)
The unique identifier for the transaction generated by the broker
and returned in the corresponding Enquire transaction.
3.12. Transaction: Respond
Request: RespondRequest
Response:RespondResponse
Respond to a confirmation request.
Hallam-Baker Expires November 11, 2017 [Page 21]
Internet-Draft Mesh/Confirm May 2017
3.12.1. Message: RespondRequest
o
* Inherits: ConfirmRequest
Respond to a confirmation request.
Response: JoseWebEncryption (Optional)
Signed and optionally encrypted response message.
3.12.2. Message: RespondResponse
o
* Inherits: ConfirmResponse
Reports the success or failure of a Respond transaction.
[None]
4. Simple Request Markup Language (SRMLv1)
Confirmation requests are posted in SRML, a deliberately limited
subset of HTML. SRML is limited to four elements and one attribute.
These are:
The top-level element for an SRML request
5. Heading Text
Heading
Running text
Paragraph
User option
Button specifying a value that the user can select.
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
Hallam-Baker Expires November 11, 2017 [Page 22]
Internet-Draft Mesh/Confirm May 2017
SRML document is a single form and the form action to be performed is
impicit in the presentation of the document to the user.
5.1. XML Schema and Content Type Identifier
The MIME Content Type and schema identifier for SRML are
Content-Type
text/xml
xmlns
http://hallambaker.com/Schemas/srml.xsd
The schema is
Hallam-Baker Expires November 11, 2017 [Page 23]
Internet-Draft Mesh/Confirm May 2017
5.2. Design considerations and future options
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.
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.
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.
6. Security Considerations
Consider spam control, how do users prevent unwanted requests? (EV
accreditatio, filtering at Broker)
People deploying Mesh/Confirm as a means of controlling access to
networking infrastructure must consider the bootstrap issue. In
particular since Mesh/Confirm 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.
7. Acknowledgements
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
Email: philliph@comodo.com
Hallam-Baker Expires November 11, 2017 [Page 24]