Skip to content

Commit 1dec6e3

Browse files
kmonsenkmonsen
authored
Add files via upload
1 parent ce44942 commit 1dec6e3

File tree

1 file changed

+377
-0
lines changed

1 file changed

+377
-0
lines changed

‎spec.bs

+377
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,377 @@
1+
<pre class="metadata">
2+
Title: Device Bound Session Credentials
3+
Shortname: dbsc
4+
Level: 1
5+
Indent: 2
6+
Status: ED
7+
TR: https://www.w3.org/TR/dbsc/
8+
Group: WebAppSec
9+
URL: https://wicg.github.io/dbsc/
10+
Editor: Kristian Monsen 76841, Google, [email protected]
11+
Abstract: The Device Bound Sessions Credentials (DBSC) aims to prevent hijacking via cookie theft by building a protocol and infrastructure that allows a user agent to assert possession of a securely-stored private key. DBSC is a Web API and protocol between user agents and servers to achieve this binding.
12+
Repository: https://github.com/WICG/dbsc/
13+
Markup Shorthands: css no, markdown yes
14+
Mailing List:
15+
</pre>
16+
17+
<pre class="link-defaults">
18+
spec:dom; type:interface; for:/; text:Document
19+
spec:dom; type:dfn; for:/; text:element
20+
spec:url; type:dfn; for:url; text:origin
21+
spec:fetch; type:dfn; for:Response; text:response
22+
spec:html; type:element; text:script
23+
spec:html; type:element; text:link
24+
spec:fetch; type:dfn; text:name
25+
spec:fetch; type:dfn; text:value
26+
spec:infra; type:dfn; text:list
27+
spec:permissions; type:dfn; text:feature
28+
</pre>
29+
30+
<pre class="anchors">
31+
spec:payment-request; urlPrefix: https://w3c.github.io/payment-request/
32+
type: dfn
33+
text: PaymentRequest; url: dom-paymentrequest
34+
spec:reporting; urlPrefix: https://w3c.github.io/reporting/
35+
type: dfn
36+
text: report type
37+
text: visible to reportingobservers
38+
spec: RFC8941; urlPrefix: https://datatracker.ietf.org/doc/html/rfc8941#
39+
type: dfn
40+
text: sf-dictionary; url: dictionary
41+
</pre>
42+
43+
<section>
44+
<h2 id="intro">Introduction</h2>
45+
46+
<em>This section is not normative.</em>
47+
48+
The web is built on a stateless protocol, to provide required functionality
49+
Web applications store data locally on a user's computer in order to provide
50+
functionality the are very common today. Primarily this is used for logged in
51+
user sessions that can last for a long time.
52+
53+
In general user agents do not have a secure way of storing files supporting
54+
these activities across commonly used operating systems, and actions may have
55+
serious consequences, for example transferring money from a bank account.
56+
57+
This document defines a new mechanism that enables the server to verify that a
58+
session cannot be exported from a device by using commonly available TPMs that
59+
are designed for this purpose.
60+
61+
The goal is to provide the end user with a safe and securing experience that
62+
is providing opportunities and does not have unreasonable friction as part of
63+
the user experience.
64+
65+
<h3 id="examples">Examples</h3>
66+
67+
<h4 id="example-signin">Signed in session</h4>
68+
<div class="example">
69+
A user logs in to his social account, to protect the user's private
70+
data the site protects his logged in session wwith a DBSC session.
71+
If the user tries to log with the same cookie file on a different device,
72+
the site can detect and refuse this as an unathorized user.
73+
</div>
74+
75+
<h4 id="example-device-integrity">Device integrity</h4>
76+
<div class="example">
77+
A commercial site has different ways of detecting unahtorized log-in
78+
attempts. A DBSC session on device could be used to see which users
79+
has logged on to this device before.
80+
</div>
81+
82+
<h4 id="example-device-reputation">Device reputation</h4>
83+
<div class="example">
84+
A payment company hosted at site `payment.example` could
85+
create a session bound to when users visit commercial site
86+
`shopping.example`. It could track the reliability
87+
of the device over time to decide how likely a transaction
88+
is legitimate.
89+
</div>
90+
91+
<h4 id="example-enterprise-sso">Enterprise example</h4>
92+
<div class="example">
93+
Describe some enterprise scenario
94+
</div>
95+
96+
<h4 id="example-enterprise-continuity">Enterprise example</h4>
97+
<div class="example">
98+
In an enterprise scenario, the user session can be attested
99+
to be bound to the same TPM as a the device owner has in inventory management.
100+
</div>
101+
102+
<h3 id="goals">Goals</h3>
103+
<h3 id="non-goals">Non-goals</h3>
104+
</section>
105+
106+
<section>
107+
<h2 id="privacy">Privacy</h2>
108+
<h3 id="privacy-cookies">Cookies and privacy</h3>
109+
</section>
110+
111+
<section>
112+
<h2 id="framework">Framework</h2>
113+
This document uses ABNF grammar to specify syntax, as defined in [[!RFC5234]] and updated in
114+
[[!RFC7405]], along with the `#rule` extension defined in
115+
<a href="https://tools.ietf.org/html/rfc7230#section-7">Section 7</a> of [[!RFC9112]], and the
116+
`quoted-string` rule defined in
117+
<a href="https://tools.ietf.org/html/rfc7230#section-3.2.6">Section 3.2.6</a> of the same
118+
document.
119+
120+
This document depends on the Infra Standard for a number of foundational concepts used in its
121+
algorithms and prose [[!INFRA]].
122+
123+
<h3 id="framework-sessions-origin">Sessions by registrable domain</h3>
124+
<p>A <dfn>registrable domain sessions</dfn> is a [=ordered map=] from [=host/registrable domain=]
125+
to [=session by id=]</p>
126+
127+
<h3 id="framework-sessions-origin">Sessions by id</h3>
128+
<p>A <dfn>session by id</dfn> is an [=ordered map=] from [=device bound session/session identifier=]
129+
to [=device bound session=]s for a given [=host/registrable domain=]</p>
130+
131+
<h3 id="framework-session">Device bound session</h3>
132+
<p>A <dfn>device bound session</dfn> is a [=struct=] with the following
133+
[=struct/items=]:</p>
134+
<dl dfn-for="device bound session">
135+
: <dfn>session identifier</dfn>
136+
:: an [=string=] that is a unique identifier of a session on an [=host/registrable domain=]
137+
: <dfn>refresh url</dfn>
138+
:: an [=string=] that is representing the [=url=] to be used to refresh the session
139+
: <dfn>defer requests</dfn>
140+
:: an OPTIONAL [=boolean=] defining if the browser should defer other requests while refreshing a session
141+
: <dfn>cached challenge</dfn>
142+
:: an [=string=] that is to be used as the next challenge for this session [=origin=]
143+
: [=session scope=]
144+
:: a [=struct=] defining which [=url=]'s' are in scope for this session
145+
: [=session credential=]
146+
:: a [=list=] of [=session credential=] used by the session
147+
</dl>
148+
149+
<h3 id="framework-scope">Session scope</h3>
150+
<p>The <dfn>session scope</dfn> is a [=struct=] with the following
151+
[=struct/items=]:</p>
152+
<dl dfn-for="session scope">
153+
: <dfn>origin</dfn>
154+
:: an [=string=] representing the [=origin=] of the session (|origin|)
155+
: <dfn>include site</dfn>
156+
:: a [=boolean=] that indicates if all subdomains of [=session scope/origin=] are included by default. This can only be true if [=session scope/origin=] is an eTLD+1
157+
: [=scope specification=]
158+
:: a [=list=] of [=scope specification=] used by the session
159+
</dl>
160+
161+
<h3 id="framework-scope-specification">Scope specification</h3>
162+
<p>The <dfn>scope specification</dfn> is a [=struct=] with the following
163+
[=struct/items=]:</p>
164+
<dl dfn-for="scope specification">
165+
: <dfn>type</dfn>
166+
:: a [=string=] to be either "include" or "exclude", defining if the item defined in this struct should be added or removed from the scope
167+
: <dfn>domain</dfn>
168+
:: a [=string=] that defines the [=origin=] of this struct. This needs to be the [=scope specification/domain=] or a subdomain of [=scope specification/domain=]
169+
: <dfn>path</dfn>
170+
:: a [=string=] that defines the path part of this scope item
171+
</dl>
172+
173+
<h3 id="framework-session-credential">Session credential</h3>
174+
<p>The <dfn>session credential</dfn> is a [=struct=] with the following
175+
[=struct/items=]:</p>
176+
<dl dfn-for="session credential">
177+
: <dfn>name</dfn>
178+
:: a [=string=] that defines the name of the credential cookie
179+
: <dfn>attributes</dfn>
180+
:: a [=string=] that defines the other attributes of the credential cookie
181+
</dl>
182+
</section>
183+
184+
<section>
185+
<h2 id="algorithm">Algorithms</h2>
186+
<section>
187+
## <dfn export abstract-op id="identify-session">Identify session</dfn> ## {#algo-identify-session}
188+
189+
<div class="algorithm" data-algorithm="identify-session">
190+
Given a [=url=] and [=device bound session/session identifier=]
191+
(|session identifier|), this algorithm returns a
192+
[=device bound session=].
193+
194+
1. Let |site| be the [=host/registrable domain=] of the [=url=]
195+
1. Let |domain sessions| be [=registrable domain sessions=][|site|]
196+
1. Let |policy| be the result of executing <a abstract-op>Construct policy
197+
from dictionary and origin</a> on |parsed header| and |origin|.
198+
</div>
199+
</section>
200+
201+
<section>
202+
## <dfn export abstract-op id="process-challenge">Process challenge</dfn> ## {#algo-process-challenge}
203+
204+
<div class="algorithm" data-algorithm="process-challenge">
205+
Given a [=response=] (|response|), an [=origin=] (|origin|), this
206+
algorithm updates the [=device bound session/cached challenge=] for a
207+
[=device bound session=].
208+
209+
1. Let |header name| be "<code>Sec-Session-Challenge</code>".
210+
1. Let |parsed header| be the result of executing <a>get a structured
211+
field value</a> given |header name| and "dictionary" from |response|’s
212+
[=response/header list=].
213+
1. Let |policy| be the result of executing <a abstract-op>Construct policy
214+
from dictionary and origin</a> on |parsed header| and |origin|.
215+
</div>
216+
</section>
217+
218+
<h3 id="algorithm-register-session">Registering a new session</h2>
219+
<h3 id="algorithm-refresh-session">Refreshing an existing session</h2>
220+
<h3 id="algorithm-closing-session">Closing an existing session</h2>
221+
</section>
222+
223+
<section>
224+
<h2 id="format">DBSC Formats</h2>
225+
<h3 id="header-sec-session-registration">`Sec-Session-Registration` HTTP Header Field</h3>
226+
227+
<h3 id="header-sec-session-challenge">\``Sec-Session-Challenge`\` HTTP Header Field</h3>
228+
<p>The \`<dfn export http-header id="sec-session-challenge-header">
229+
<code>Sec-Session-Challenge</code></dfn>\` header field can be used in the
230+
[=response=] by the server to send a challenge to the client that it expects
231+
to be used in future Sec-Session-Request headers inside the DBSC proof
232+
JWT.</p>
233+
<p>\`<a http-header><code>Permissions-Policy</code></a>\` is a structured
234+
header. Its value must be a dictionary. It's ABNF is:</p>
235+
<pre class="abnf">SecSessionChallange = <a>sf-dictionary</a></pre>
236+
The semantics of the dictionary are defined in
237+
[[#structured-header-serialization]].
238+
239+
The processing steps are defined in [[#algo-process-challenge]].
240+
241+
<section>
242+
<h4 id="structured-header-serialization">Structured header serialization</h4>
243+
<a>Policy Directives</a> in HTTP headers are represented as Structured
244+
Fields. [[!RFC8941]]
245+
246+
In this representation, a <a>policy directive</a> is represented by a
247+
Dictionary.
248+
249+
Each Dictionary Member associates a
250+
<a data-lt="policy-controlled feature">feature</a> with an
251+
<a>allowlist</a>. The Member Names must be Tokens. If a token does not
252+
name one of the user agent's [=supported features=], then the Dictionary
253+
Member will be ignored by the processing steps.
254+
255+
The Member Values represent <a>allowlists</a>, and must be one of:
256+
* a String containing the ASCII <a>permissions-source-expression</a>
257+
* the Token `*`
258+
* the Token `self`
259+
* an Inner List containing zero or more of the above items.
260+
261+
Member Values may have a Parameter named `"report-to"`, whose value must
262+
be a String. Any other parameters will be ignored.
263+
264+
Any other items inside of an Inner List will be ignored by the processing
265+
steps, and the Member Value will be processed as if they were not present.
266+
Member Values of any other form will cause the entire Dictionary Member to
267+
be ignored by the processing steps.
268+
</section>
269+
270+
<h3 id="header-sec-session-response">`Sec-Session-Response` HTTP Header Field</h3>
271+
272+
<h3 id="header-sec-session-id">`Sec-Session-Id` HTTP Header Field</h3>
273+
274+
<h3 id="format-session-instructions">DBSC Session Instruction Format</h3>
275+
276+
<h3 id="format-jwt">DBSC Proof JWTs</h3>
277+
</section>
278+
279+
<section>
280+
<h2 id="changes-to-other-specifications">Changes to other specifications</h2>
281+
<h3 id="changes-to-html">Changes to the HTML specification</h3>
282+
</section>
283+
284+
<section>
285+
<h2 id="iana-considerations">IANA Considerations</h2>
286+
287+
The permanent message header field registry should be updated
288+
with the following registrations: [[!RFC3864]]
289+
290+
<h3 id="iana-ses-session-challenge">
291+
Sec-Session-Challenge
292+
</h3>
293+
<dl>
294+
<dt>Header field name</dt>
295+
<dd>Sec-Session-Challenge</dd>
296+
297+
<dt>Applicable protocol</dt>
298+
<dd>http</dd>
299+
300+
<dt>Status</dt>
301+
<dd>draft</dd>
302+
303+
<dt>Author/Change controller</dt>
304+
<dd>W3C</dd>
305+
306+
<dt>Specification document</dt>
307+
<dd>This specification (See [[#header-sec-session-challenge]])</dd>
308+
</dl>
309+
310+
<h3 id="iana-ses-session-id">
311+
Sec-Session-Id
312+
</h3>
313+
<dl>
314+
<dt>Header field name</dt>
315+
<dd>Sec-Session-Id</dd>
316+
317+
<dt>Applicable protocol</dt>
318+
<dd>http</dd>
319+
320+
<dt>Status</dt>
321+
<dd>draft</dd>
322+
323+
<dt>Author/Change controller</dt>
324+
<dd>W3C</dd>
325+
326+
<dt>Specification document</dt>
327+
<dd>This specification (See [[#header-sec-session-id]])</dd>
328+
</dl>
329+
330+
<h3 id="iana-sec-session-registration">
331+
Sec-Session-Registration
332+
</h3>
333+
<dl>
334+
<dt>Header field name</dt>
335+
<dd>Sec-Session-Registration</dd>
336+
337+
<dt>Applicable protocol</dt>
338+
<dd>http</dd>
339+
340+
<dt>Status</dt>
341+
<dd>draft</dd>
342+
343+
<dt>Author/Change controller</dt>
344+
<dd>W3C</dd>
345+
346+
<dt>Specification document</dt>
347+
<dd>This specification (See [[#header-sec-session-registration]])</dd>
348+
</dl>
349+
350+
<h3 id="iana-ses-session-response">
351+
Sec-Session-Response
352+
</h3>
353+
<dl>
354+
<dt>Header field name</dt>
355+
<dd>Sec-Session-Response</dd>
356+
357+
<dt>Applicable protocol</dt>
358+
<dd>http</dd>
359+
360+
<dt>Status</dt>
361+
<dd>draft</dd>
362+
363+
<dt>Author/Change controller</dt>
364+
<dd>W3C</dd>
365+
366+
<dt>Specification document</dt>
367+
<dd>This specification (See [[#header-sec-session-response]])</dd>
368+
</dl>
369+
</section>
370+
371+
<section>
372+
<h2 id="changelog">Changelog</h2>
373+
</section>
374+
375+
<section>
376+
<h2 id="acknowledgements">Acknowledgements</h2>
377+
</section>

0 commit comments

Comments
 (0)