OBP-Connection.xml





<section title="OBPConnection">


<section title="Message: Message">


<!-- No parameters -->

</section>
<section title="Message: Response">


<t> <list style="hanging" hangIndent="6">
<t hangText="Status : Integer [0..1]   "></t>
<t>
Application layer server status code
</t>
<t hangText="StatusDescription : String [0..1]   "></t>
<t>
Describes the status code (ignored by processors)
</t>
</list></t>

</section>
<section title="Message: ErrorResponse">

<t>
An error response MAY be returned in response to any request.
</t>
<t>
Note that requests MAY be rejected by the code implementing
the transport binding before application processing begins
and so a server is not guaranteed to provide an error response
message.
</t>

<!-- No parameters -->

</section>
<section title="Message: Request">


<!-- No parameters -->

</section>
<section title="Structure: Cryptographic">

<t>
Parameters describing a cryptographic context.
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="Protocol : Label [0..1]   "></t>
<t>
OBP tickets MAY be restricted to use with either the management
protocol (Management) or the query protocol (Query). If so a 
service would typically 
specify a ticket with a long expiry time or no expiry for use with 
the management protocol and a separate ticket for use with the 
query protocol.
</t>
<t hangText="Secret : Binary [1..1]   "></t>
<t>
Shared secret
</t>
<t hangText="Encryption : Label [1..1]   "></t>
<t>
Encryption Algorithm selected
</t>
<t hangText="Authentication : Label [1..1]   "></t>
<t>
Authentication Algorithm selected
</t>
<t hangText="Ticket : Binary [1..1]   "></t>
<t>
Opaque ticket issued by the server that identifies
the cryptographic parameters for encryption and
authentication of the message payload.
</t>
<t hangText="Expires : DateTime [0..1]   "></t>
<t>
Date and time at which the context will expire
</t>
</list></t>

</section>
<section title="Structure: ImageLink">


<t> <list style="hanging" hangIndent="6">
<t hangText="Algorithm : Label [0..1]   "></t>
<t>
Image encoding algorithm (e.g. JPG, PNG)
</t>
<t hangText="Image : Binary [0..1]   "></t>
<t>
Image data as specified by algorithm
</t>
</list></t>

</section>
<section title="Structure: Connection">

<t>
Contains information describing a network connection.
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="Name : Name [0..1]   "></t>
<t>
DNS Name. Since one of the functions of an OBP service is name
resolution, a DNS name is only used to establish a connection if
connection by means of the IP address fails.
</t>
<t hangText="Port : Integer [0..1]   "></t>
<t>
TCP or UDP port number.
</t>
<t hangText="Address : String [0..1]   "></t>
<t>
IPv4 (32 bit) or IPv6 (128 bit) service address
</t>
<t hangText="Priority : Integer [0..1]   "></t>
<t>
Service priority. Services with lower priority numbers SHOULD
be attempted before those with higher numbers.
</t>
<t hangText="Weight : Integer [0..1]   "></t>
<t>
Weight to be used to select between services of equal priority.
</t>
<t hangText="Transport : Label [0..1]   "></t>
<t>
OBP Transport binding to be used valid values are HTTP, DNS and UDP.
</t>
<t hangText="Expires : DateTime [0..1]   "></t>
<t>
Date and time at which the specified connection context will expire.
</t>
<t hangText="Cryptographic : Cryptographic [0..1]   "></t>
<t>
Cryptographic Parameters.
</t>
</list></t>

</section>
<section title="Bind">

<t>
Binding a device is a two step protocol that begins with the
Start Query followed by a sequence of Ticket queries.
</t>

</section>
<section title="Message: BindRequest">

<t>
The following parameters MAY occur in either a
StartRequest or TicketRequest:
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="Encryption : Label [0..Many]   "></t>
<t>
Encryption Algorithm that the client accepts. A Client MAY
offer multiple algorithms. If no algorithms are specified then
support for the mandatory to implement algorithm is assumed.
Otherwise mandatory to implement algorithms MUST be 
specified explicitly.
</t>
<t hangText="Authentication : Label [0..Many]   "></t>
<t>
Authentication Algorithm that the client accepts.
If no algorithms are specified then
support for the mandatory to implement algorithm is assumed.
Otherwise mandatory to implement algorithms MUST be 
specified explicitly. 
</t>
</list></t>

</section>
<section title="Message: BindResponse">

<t>
The following parameters MAY occur in either a
StartResponse or TicketResponse:
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="Cryptographic : Cryptographic [0..Many]   "></t>
<t>
Cryptographic Parameters.
</t>
<t hangText="Service : Connection [0..Many]   "></t>
<t>
A Connection describing an OBP service point
</t>
</list></t>

</section>
<section title="Message: OpenRequest">

<t>
The OpenRequest Message is used to begin a device binding transaction.
Depending on the authentication requirements of the service the
transaction may be completed in a single query or require a 
further Ticket Query to complete.
</t>
<t>
If authentication is required, the mechanism to be used depends on
the capabilities of the device, the requirements of the broker and
the existing relationship between the user and the broker.
</t>
<t>
If the device supports some means of data entry, authentication 
MAY be achieved by entering a passcode previously delivered out
of band into the device.
</t>
<t>
The OpenRequest specifies the properties of the service
(Account, Domain) and Device (ID, URI, Name) that will remain
constant throughout the period that the device binding is active
and parameters to be used for the mutual authentication protocol.
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="Account : String [0..1]   "></t>
<t>
Account name of the user at the OBP service
</t>
<t hangText="Domain : Name [0..1]   "></t>
<t>
Domain name of the OBP broker service
</t>
<t hangText="HavePasscode : Boolean [0..1]  Default =False "></t>
<t>
If 'true', the user has entered a passcode value for 
use with passcode authentication.
</t>
<t hangText="HaveDisplay : Boolean [0..1]  Default =False "></t>
<t>
Specifies if the device is capable of displaying information
to the user or not.
</t>
<t hangText="Challenge : Binary [0..1]   "></t>
<t>
Client challenge value to be used in authentication challenge
mechanism as described in section <xref target="ChallengeResponse"/>
</t>
<t hangText="DeviceID : URI [0..1]   "></t>
<t>
Device identifier unique for a particular instance of a device such as a MAC or EUI-64 address expressed as a URI
</t>
<t hangText="DeviceURI : URI [0..1]   "></t>
<t>
Device identifier specifying the type of device, e.g. an xPhone.
</t>
<t hangText="DeviceImage : ImageLink [0..1]   "></t>
<t>
An image identifying the physical appearance of the device. 
</t>
<t hangText="DeviceName : String [0..1]   "></t>
<t>
Descriptive name for the device that would distinguish it 
from other similar devices, e.g. 'Alice's xPhone".
</t>
</list></t>

</section>
<section title="Message: OpenResponse">

<t>
An Open request MAY be accepted immediately or be held pending
completion of an inband or out-of-band authentication process.
</t>
<t>
The OpenResponse returns a ticket and a set of cryptographic
connection parameters in either case. If the 
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="Challenge : Binary [0..1]   "></t>
<t>
Challenge value to be used by the client to respond
to the server authentication challenge.
</t>
<t hangText="ChallengeResponse : Binary [0..1]   "></t>
<t>
Server response to authentication challenge by the client
as described in section <xref target="ChallengeResponse"/>
</t>
<t hangText="VerificationImage : ImageLink [0..Many]   "></t>
<t>
Link to an image to be used in an image verification mechanism.
</t>
</list></t>

</section>
<section title="Message: TicketRequest">

<t>
The TicketRequest message is used to (1) complete a binding request
begun with an OpenRequest and (2) to refresh ticket or connection 
parameters as necessary.
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="ChallengeResponse : Binary [0..1]   "></t>
<t>
The response to a serer authentication challenge 
as described in section <xref target="ChallengeResponse"/>
</t>
</list></t>

</section>
<section title="Message: TicketResponse">

<t>
The TicketResponse message returns cryptographic and/or connection
context information to a client.
</t>

<!-- No parameters -->

</section>
<section title="Unbind">

<t>
Requests that a previous device association be deleted.
</t>

</section>
<section title="Message: UnbindRequest">

<t>
Since the ticket identifies the binding to be deleted, the
only thing that the unbind message need specify is that
the device wishes to cancel the binding.
</t>

<!-- No parameters -->

</section>
<section title="Message: UnbindResponse">

<t>
Reports on the success of the unbinding operation.
</t>
<t>
If the server reports success, the client SHOULD delete the
ticket and all information relating to the binding.
</t>
<t>
A service MAY continue to accept a ticket after an unbind request
has been granted but MUST NOT accept such a ticket for
a bind request.
</t>

<!-- No parameters -->

</section>

</section>