Draft: draft-ietf-rtcweb-security-arch

Commentary: Remove references to BrowserID Remove OPEN ISSUE , since that seems to be closed Remove reference non - cryptographic authentication , since that 's not used Some clarification about " partly trusted "  -Tor Browser 
 move from " currently " to some future state ? I think this is functionally : " If implementations chose to support permission grants for HTTP origins , it is RECOMMENDED that this be for one - time camera / microphone access . " maybe with " only " , given the concerns around screen - sharing . I agree with ekr that this will need consensus , however the initial phrasing is done , so I 'd suggest a slide on it for Singapore .    LGTM
Paragraph (version A):
Optimally, we would not rely on trust in any entities other than the
browser.  However, this is unfortunately not possible if we wish to
have a functional system.  Other network elements fall into two
categories: those which can be authenticated by the browser and thus
are partly trusted--though to the minimum extent necessary--and those
which cannot be authenticated and thus are untrusted.
Paragraph (version B):
Optimally, we would not rely on trust in any entities other than the
browser.  However, this is unfortunately not possible if we wish to
have a functional system.  Other network elements fall into two
categories: those which can be authenticated by the browser and thus
can be granted permissions to access sensitive resources, and those
which cannot be authenticated and thus are untrusted.
Paragraph (version A):
It's also worth noting that there are settings where authentication
is non-cryptographic, such as other machines behind a firewall.
Naturally, the level of trust one can have in identities verified in
this way depends on how strong the topology enforcement is.
Paragraph (version A):
For the purposes of this example, we assume the topology shown in the
figures below.  This topology is derived from the topology shown in
fig.simple, but separates Alice and Bob's identities from the process
of signaling.  Specifically, Alice and Bob have relationships with
some Identity Provider (IdP) that supports a protocol such as OpenID
or BrowserID) that can be used to demonstrate their identity to other
parties.  For instance, Alice might have an account with a social
network which she can then use to authenticate to other web sites
without explicitly having an account with those sites; this is a
fairly conventional pattern on the Web. sec.trust-relationships
provides an overview of Identity Providers and the relevant
terminology.  Alice and Bob might have relationships with different
IdPs as well.
Paragraph (version B):
For the purposes of this example, we assume the topology shown in the
figures below.  This topology is derived from the topology shown in
fig.simple, but separates Alice and Bob's identities from the process
of signaling.  Specifically, Alice and Bob have relationships with
some Identity Provider (IdP) that supports a protocol (such as OpenID
Connect) that can be used to demonstrate their identity to other
parties.  For instance, Alice might have an account with a social
network which she can then use to authenticate to other web sites
without explicitly having an account with those sites; this is a
fairly conventional pattern on the Web. sec.trust-relationships
provides an overview of Identity Providers and the relevant
terminology.  Alice and Bob might have relationships with different
IdPs as well.
Paragraph (version A):
For simplicity, assume the topology in fig.proposal.idp.  Alice and
Bob are both users of a common calling service; they both have
approved the calling service to make calls (we defer the discussion
of device access permissions till later).  They are both connected to
the calling service via HTTPS and so know the origin with some level
of confidence.  They also have accounts with some identity provider.
This sort of identity service is becoming increasingly common in the
Web environment (with technologies such as BrowserID, Federated
Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is
often provided as a side effect service of a user's ordinary accounts
with some service.  In this example, we show Alice and Bob using a
separate identity service, though the identity service may be the
same entity as the calling service or there may be no identity
service at all.
Paragraph (version B):
For simplicity, assume the topology in fig.proposal.idp.  Alice and
Bob are both users of a common calling service; they both have
approved the calling service to make calls (we defer the discussion
of device access permissions till later).  They are both connected to
the calling service via HTTPS and so know the origin with some level
of confidence.  They also have accounts with some identity provider.
This sort of identity service is becoming increasingly common in the
Web environment (with technologies such as Federated Google Login,
Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as
a side effect service of a user's ordinary accounts with some
service.  In this example, we show Alice and Bob using a separate
identity service, though the identity service may be the same entity
as the calling service or there may be no identity service at all.
Paragraph (version A):
Prior to sending out the signaling message, the PeerConnection code
contacts the identity service and obtains an assertion binding
Alice's identity to her fingerprint.  The exact details depend on the
identity service (though as discussed in sec.generic.idp
PeerConnection can be agnostic to them), but for now it's easiest to
think of as a BrowserID assertion.  The assertion may bind other
information to the identity besides the fingerprint, but at minimum
it needs to bind the fingerprint.
Paragraph (version B):
Prior to sending out the signaling message, the PeerConnection code
contacts the identity service and obtains an assertion binding
Alice's identity to her fingerprint.  The exact details depend on the
identity service (though as discussed in sec.generic.idp
PeerConnection can be agnostic to them), but for now it's easiest to
think of as an OAuth token.  The assertion may bind other information
to the identity besides the fingerprint, but at minimum it needs to
bind the fingerprint.
Paragraph (version A):
Because HTTP origins cannot be securely established against network
attackers, implementations MUST NOT allow the setting of permanent
access permissions for HTTP origins.  Implementations MAY also opt to
refuse all permissions grants for HTTP origins, but it is RECOMMENDED
that currently they support one-time camera/microphone access.
Paragraph (version B):
Because HTTP origins cannot be securely established against network
attackers, implementations MUST NOT allow the setting of permanent
access permissions for HTTP origins.  Implementations MUST refuse all
permissions grants for HTTP origins.
Paragraph (version A):
Torbutton [https://www.torproject.org/torbutton/]) and is out of
scope for this specification.
Paragraph (version B):
Tor Browser [https://www.torproject.org/projects/torbrowser.html.en])
and is out of scope for this specification.
Paragraph (version A):
The "security characteristics" MUST include an indication as to
whether the cryptographic keys were delivered out-of-band (from
a server) or were generated as a result of a pairwise
negotiation.
Paragraph (version A):
Recently, a number of Web-based identity technologies (OAuth,
BrowserID, Facebook Connect etc.) have been developed.  While the
details vary, what these technologies share is that they have a Web-
based (i.e., HTTP/HTTPS) identity provider which attests to your
identity.  For instance, if I have an account at example.org, I could
use the example.org identity provider to prove to others that I was
alice@example.org.  The development of these technologies allows us
to separate calling from identity provision: I could call you on
Poker Galaxy but identify myself as alice@example.org.
Paragraph (version B):
Recently, a number of Web-based identity technologies (OAuth,
Facebook Connect etc.) have been developed.  While the details vary,
what these technologies share is that they have a Web-based (i.e.,
HTTP/HTTPS) identity provider which attests to your identity.  For
instance, if I have an account at example.org, I could use the
example.org identity provider to prove to others that I was
alice@example.org.  The development of these technologies allows us
to separate calling from identity provision: I could call you on
Poker Galaxy but identify myself as alice@example.org.
Paragraph (version A):
Whatever the underlying technology, the general principle is that the
party which is being authenticated is NOT the signaling site but
rather the user (and their browser).  Similarly, the relying party is
the browser and not the signaling site.  Thus, the browser MUST
securely generate the input to the IdP assertion process and MUST
securely display the results of the verification process to the user
in a way which cannot be imitated by the calling site.
Paragraph (version B):
Whatever the underlying technology, the general principle is that the
party which is being authenticated is NOT the signaling site but
rather the user (and their browser).  Similarly, the relying party is
the browser and not the signaling site.  Thus, the browser MUST
generate the input to the IdP assertion process and display the
results of the verification process to the user in a way which cannot
be imitated by the calling site.