Subject: [OAUTH-WG] Privacy Considerations section in OAuth 2.1?

From: Dick Hardt <[email-masked]>
Date: Mon, 10 Aug 2020 09:41:55 -0700

In the PAR meeting today, Denis requested there be a privacy considerations
section in PAR. I don't think there is anything specific in PAR that would
change the privacy considerations of OAuth, and am checking if there is WG
interest, and consensus, on including a Privacy Considerations section in
the OAuth 2.1 draft.

/Dick
ᐧ

---

From: Brian Campbell <[email-masked]>
Date: Mon, 10 Aug 2020 11:03:44 -0600

I didn't have the reference offhand during the meeting today but
https://tools.ietf.org/html/rfc6973 looks to be a good source of
considerations for writing privacy considerations. As I mentioned, I've
written a number of such sections. Though these probably shouldn't be
considered exemplary they were published:
https://tools.ietf.org/html/rfc8707#section-4,
https://tools.ietf.org/html/rfc8705#section-8https://tools.ietf.org/html/rfc8693#section-6
<https://tools.ietf.org/html/rfc8693#section-6>,
https://tools.ietf.org/html/rfc7523#section-7,
https://tools.ietf.org/html/rfc7522#section-7, and
https://tools.ietf.org/html/rfc7521#section-8.4.

<https://tools.ietf.org/html/rfc7521#section-8.4>

I think including a pragmatic Privacy Considerations section in the OAuth
2.1 draft could be worthwhile.

On Mon, Aug 10, 2020 at 10:42 AM Dick Hardt <[email-masked]> wrote:

> In the PAR meeting today, Denis requested there be a privacy
> considerations section in PAR. I don't think there is anything specific in
> PAR that would change the privacy considerations of OAuth, and am checking
> if there is WG interest, and consensus, on including a Privacy
> Considerations section in the OAuth 2.1 draft.
>
> /Dick
> ᐧ
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 10 Aug 2020 10:20:27 -0700

I agree that there is nothing unique to PAR that would justify adding the
privacy considerations mentioned to that draft. I wouldn't oppose adding a
privacy considerations section to OAuth 2.1 though.

Aaron

---

From: Filip Skokan <[email-masked]>
Date: Mon, 10 Aug 2020 19:47:28 +0200

I don’t think there’s anything new introduced in PAR that would alter existing status quo of privacy consiserations. As such if privacy consideration was to be added for completeness it should be along the lines of “this document does not expand on or otherwise alter the privacy considerations” or “there are no new privacy considerations introduced by this document”. 

Filip

Odesláno z iPhonu

> 10. 8. 2020 v 19:21, Aaron Parecki <[email-masked]>:
> 
> 
> I agree that there is nothing unique to PAR that would justify adding the privacy considerations mentioned to that draft. I wouldn't oppose adding a privacy considerations section to OAuth 2.1 though.
> 
> Aaron
> 
> 
>> In the PAR meeting today, Denis requested there be a privacy considerations section in PAR. I don't think there is anything specific in PAR that would change the privacy considerations of OAuth, and am checking if there is WG interest, and consensus, on including a Privacy Considerations section in the OAuth 2.1 draft.
>> 
>> /Dick
>> ᐧ

---

From: Denis <[email-masked]>
Date: Tue, 11 Aug 2020 16:43:51 +0200

OAuth 2. 0 and the OAuth 2.1 draft share a common point: they do not 
include a Privacy considerations section.

This is "normal" for OAuth 2. 0 since RFC 6749 was published before RFC 
6973 ever existed.

RFC 6973 is a good guidance document that should be read and used to add 
a Privacy Considerations section to the OAuth 2.1 draft.

Denis

> considerations for writing privacy considerations. As I mentioned, 
> I've written a number of such sections. Though these probably 
> shouldn't be considered exemplary they were published: 
> I think including a pragmatic Privacy Considerations section in the 
> OAuth 2.1 draft could be worthwhile.
>
> On Mon, Aug 10, 2020 at 10:42 AM Dick Hardt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     considerations section in PAR. I don't think there is anything
>     specific in PAR that would change the privacy considerations of
>     OAuth, and am checking if there is WG interest, and consensus, on
>     including a Privacy Considerations section in the OAuth 2.1 draft.
>
>     /Dick
>     ᐧ
>     [email-masked] <mailto:[email-masked]>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> privileged material for the sole use of the intended recipient(s). Any 
> review, use, distribution or disclosure by others is strictly 
> prohibited..  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./
>

---

From: Denis <[email-masked]>
Date: Tue, 11 Aug 2020 16:46:46 +0200

Hi Filip,

> I don’t think there’s anything new introduced in PAR that would alter 
> existing status quo of privacy consiserations.
> As such if privacy consideration was to be added for completeness it 
> should be along the lines of “this document
> does not expand on or otherwise alter the privacy considerations” or 
> “there are no new privacy considerations introduced by this document”.

OAuth 2.0 (RFC 6749) had no Privacy considerations section as it was 
issued before RFC 6973 (Privacy Considerations for Internet Protocols) 
existed.

I browsed through the RFCs published by this WG and the guidance 
provided in RFC 6973 has not really be used and followed.

So adding no text to nearly zero text will not help that much. I believe 
that a Privacy considerations section will be added to the OAuth 2.1 draft.
While doing that exercise, a shorter version of it could be included in PAR.

Hereafter is my detailed analysis:

RFC 6973 (Privacy Considerations for Internet Protocols) has been issued 
in July 2013.RFCs issued earlier to RFC 6973 do not include a Privacy 
Considerations section.

This is the case for :

  -RFC 6749 (The OAuth 2.0 Authorization Framework)

  -RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage)

  -RFC 6755 (An IETF URN Sub-Namespace for OAuth)

  -RFC 6819 (OAuth 2.0 Threat Model and Security Considerations)

  For RFCs issued after RFC 6973, six of them don't have a have a
  Privacy Considerations section. This is the case for:

  -*RFC 7009 *(OAuth 2.0 Token Revocation)

  - *    RFC 7519* updated by RFC 8725 (JSON Web Token Best Current
  Practices)

  -*RFC 7636* (Proof Key for Code Exchange by OAuth Public Clients)

  -*RFC 8252 *(OAuth 2.0 for Native Apps) does not have a Privacy
  Considerations section

  -*RFC 8414 *(OAuth 2.0 Authorization Server Metadata)

  -*RFC 8628* (OAuth 2.0 Device Authorization Grant)

  Eleven of them have a Privacy Considerations section. They are
  enumerated below, with a copy of these sections.

  -*RFC 7521* (Assertion Framework for OAuth 2.0 Client Authentication
  and Authorization Grants)

  8.4.Privacy Considerations

  An assertion may contain privacy-sensitive information and, to prevent
  disclosure of such information to unintended parties,
  should only be transmitted over encrypted channels, such as TLS.In
  cases where it is desirable to prevent disclosure of
  certain information to the client, the assertion (or portions of it)
  should be encrypted to the authorization server.

  Deployments should determine the minimum amount of information
  necessary to complete the exchange and include only
  such information in the assertion.In some cases, the Subject
  identifier can be a value representing an anonymous or pseudonymous
  user, as described in Section 6.3.1.

  -*RFC 7522* (Security Assertion Markup Language (SAML) 2.0 Profile for
  OAuth 2.0 Client Authentication and Authorization Grants

    7. Privacy Considerations

A SAML Assertion may contain privacy-sensitive information and, to 
prevent disclosure of such information to unintended parties, should 
only be transmitted over encrypted channels, such as Transport Layer 
Security (TLS).In cases where it is desirable to prevent disclosure of 
certain information to the client, the Subject and/or individual 
attributes of a SAML Assertion should be encrypted to the authorization 
server.

Deployments should determine the minimum amount of information necessary 
to complete the exchange and include only that information in an 
Assertion (typically by limiting what information is included in an 
<AttributeStatement> or by omitting it altogether).In some cases, the 
Subject can be a value representing an anonymous or pseudonymous user, 
as described in Section 6.3.1 
<https://tools.ietf.org/html/rfc7522#section-6.3.1> of the OAuth 
Assertion Framework [RFC7521 <https://tools.ietf.org/html/rfc7521>].

  -*RFC 7523 *JSON Web Token (JWT) Profile for OAuth 2.0 Client
  Authentication and Authorization Grants

  7.Privacy Considerations

  A JWT may contain privacy-sensitive information and, to prevent
  disclosure of such information to unintended parties, should only be
  transmitted
  over encrypted channels, such as Transport Layer Security (TLS).In
  cases where it is desirable to prevent disclosure of certain
  information to the client,
  the JWT should be encrypted to the authorization server.

  Deployments should determine the minimum amount of information
  necessary to complete the exchange and include only such claims in the
  JWT.
  In some cases, the "sub" (subject) claim can be a value representing
  an anonymous or pseudonymous user, as described in Section 6.3.1 of
  the OAuth Assertion Framework [RFC7521].

  -*RFC 7591* (OAuth 2.0 Dynamic Client Registration Protocol)

  6.Privacy Considerations

  As the protocol described in this specification deals almost
  exclusively with information about software and not people, there are
  very few
  privacy concerns for its use.The notable exception is the "contacts"
  field as defined in Section 2, which contains contact information for
  the developers or other parties responsible for the client
  software.These values are intended to be displayed to end- users and
  will be available
  to the administrators of the authorization server.As such, the
  developer may wish to provide an email address or other contact
  information expressly
  dedicated to the purpose of supporting the client instead of using
  their personal or professional addresses.Alternatively, the developer
  may wish
  to provide a collective email address for the client to allow for
  continuing contact and support of the client software after the
  developer moves on and
  someone else takes over that responsibility.

  In general, the metadata for a client, such as the client name and
  software identifier, are common across all instances of a piece of
  client software
  and therefore pose no privacy issues for end-users. Client
  identifiers, on the other hand, are often unique to a specific
  instance of a client.
  For clients such as web sites that are used by many users, there may
  not be significant privacy concerns regarding the client identifier,
  but for clients
  such as native applications that are installed on a single end-user's
  device, the client identifier could be uniquely tracked during OAuth
  2.0 transactions
  and its use tied to that single end-user.However, as the client
  software still needs to be authorized by a resource owner through an
  OAuth 2.0
  authorization grant, this type of tracking can occur whether or not
  the client identifier is unique by correlating the authenticated
  resource owner with
  the requesting client identifier.

  Note that clients are forbidden by this specification from creating
  their own client identifier.If the client were able to do so, an
  individual client instance
  could be tracked across multiple colluding authorization servers,
  leading to privacy and security issues. Additionally, client
  identifiers are generally issued
  uniquely per registration request, even for the same instance of
  software.In this way, an application could marginally improve privacy
  by registering
  multiple times and appearing to be completely separate
  applications.However, this technique does incur significant usability
  cost in the form of requiring
  multiple authorizations per resource owner and is therefore unlikely
  to be used in practice.

  -*RFC 7592* (OAuth 2.0 Dynamic Client Registration Management Protocol)

  6.Privacy Considerations

  This specification poses no additional privacy considerations beyond
  those described in the core "OAuth 2.0 Dynamic Client Registration
  Protocol" [RFC7591].

  -***RFC 7662 *(OAuth 2.0 Token Introspection)

  5.Privacy Considerations

  The introspection response may contain privacy-sensitive information
  such as user identifiers for resource owners.When this is the case,
  measures MUST be taken to prevent disclosure of this information to
  unintended parties.One method is to transmit user identifiers as
  opaque service-specific
  strings, potentially returning different identifiers to each protected
  resource.

  If the protected resource sends additional information about the
  client's request to the authorization server (such as the client's IP
  address) using an extension
  of this specification, such information could have additional privacy
  considerations that the extension should detail.However, the nature
  and implications of such
  extensions are outside the scope of this specification.

  Omitting privacy-sensitive information from an introspection response
  is the simplest way of minimizing privacy issues.

  -*RFC 7800* (Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)

  5.Privacy Considerations

  A proof-of-possession key can be used as a correlation handle if the
  same key is used with multiple parties.Thus, for privacy reasons, it
  is recommended
  that different proof-of-possession keys be used when interacting with
  different parties.

  -*RFC 8176* (Authentication Method Reference Values)

  4.Privacy Considerations

  The list of "amr" claim values returned in an ID Token reveals
  information about the way that the end user authenticated to the
  identity provider.
  In some cases, this information may have privacy implications.

  While this specification defines identifiers for particular kinds of
  credentials, it does not define how these credentials are stored or
  protected.
  For instance, ensuring the security and privacy of biometric
  credentials that are referenced by some of the defined Authentication
  Method Reference
  values is beyond the scope of this specification.

  -***RFC 8693* (OAuth 2.0 Token Exchange)

  6.Privacy Considerations

  Tokens employed in the context of the functionality described herein
  may contain privacy-sensitive information and, to prevent disclosure
  of such information to unintended parties, MUST only be transmitted
  over encrypted channels, such as Transport Layer Security (TLS).
  In cases where it is desirable to prevent disclosure of certain
  information to the client, the token MUST be encrypted to its intended
  recipient.
  Deployments SHOULD determine the minimally necessary amount of data
  and only include such information in issued tokens.In some cases,
  data minimization may include representing only an anonymous or
  pseudonymous user.

  -***RFC 8705* (OAuth 2.0 Mutual-TLS Client Authentication and
  Certificate-Bound Access Tokens)

  8.Privacy Considerations

  In TLS versions prior to 1.3, the client's certificate is sent
  unencrypted in the initial handshake and can potentially be used by
  third parties
  to monitor, track, and correlate client activity.This is likely of
  little concern for clients that act on behalf of a significant number
  of end users
  because individual user activity will not be discernible amidst the
  client activity as a whole.However, clients that act on behalf of a
  single end user,
  such as a native application on a mobile device, should use TLS
  version 1.3 whenever possible or consider the potential privacy
  implications of
  using mutual TLS on earlier versions.

  -*RFC 8707* (Resource Indicators for OAuth 2.0)

  4.Privacy Considerations

  In typical OAuth deployments the authorization sever is in a position
  to observe and track a significant amount of user and client behavior.
  It is largely just inherent to the nature of OAuth, and this document
  does little to affect that.In some cases, however, such as when access
  token
  introspection is not being used, use of the resource parameter defined
  herein may allow for tracking behavior at a somewhat more granular
  and specific level than would otherwise be possible in its absence.

Denis

>> I agree that there is nothing unique to PAR that would justify adding 
>> the privacy considerations mentioned to that draft. I wouldn't oppose 
>> adding a privacy considerations section to OAuth 2.1 though.
>>
>> Aaron
>>
>>
>> On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt <[email-masked] 
> _______________________________________________ OAuth mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: Filip Skokan <[email-masked]>
Date: Tue, 11 Aug 2020 17:31:46 +0200

Denis, PAR is arguably not the document that should retrofit OAuth 2.0 with
a full blown Privacy Consideration section. Now, do you find the draft
introduces anything new from a privacy perspective? Does the AS get
anything other than what it already does via the authorization_endpoint
today?

For the record i'm not arguing OAuth 2.0 should be without privacy
considerations, i'm just saying - if it did, or rather, regardless if it
does or doesn't - PAR does not expand on those in any way.

S pozdravem,
*Filip Skokan*

On Tue, 11 Aug 2020 at 17:17, Denis <[email-masked]> wrote:

> I browsed through the RFCs published by this WG and the guidance provided
> in RFC 6973 has not really be used and followed.
>
> in July 2013. RFCs issued earlier to RFC 6973 do not include a Privacy
> Considerations section.
>
> This is the case for :
> -          RFC 6749 (The OAuth 2.0 Authorization Framework) -          RFC
> 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) -
> RFC 6755 (An IETF URN Sub-Namespace for OAuth) -          RFC 6819 (OAuth
> 2.0 Threat Model and Security Considerations) For RFCs issued after RFC
> 6973, six of them don't have a have a Privacy Considerations section. This
> is the case for:
> -          *RFC 7009 *(OAuth 2.0 Token Revocation) - *      RFC 7519*
> updated by RFC 8725 (JSON Web Token Best Current Practices) -          *RFC
> 7636* (Proof Key for Code Exchange by OAuth Public Clients) -          *RFC
> 8252 *(OAuth 2.0 for Native Apps) does not have a Privacy Considerations
> section -          *RFC 8414 *(OAuth 2.0 Authorization Server Metadata) -
> *RFC 8628* (OAuth 2.0 Device Authorization Grant) Eleven of them have a
> Privacy Considerations section. They are enumerated below, with a copy of
> these sections. -          *RFC 7521* (Assertion Framework for OAuth 2.0
> Client Authentication and Authorization Grants) 8.4.  Privacy
> Considerations An assertion may contain privacy-sensitive information
> and, to prevent disclosure of such information to unintended parties,
> should only be transmitted over encrypted channels, such as TLS.  In
> should be encrypted to the authorization server. Deployments should
> determine the minimum amount of information necessary to complete the
> exchange and include only
> such information in the assertion.  In some cases, the Subject identifier
> can be a value representing an anonymous or pseudonymous
> user, as described in Section 6.3.1. -          *RFC 7522* (Security
> Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client
> Authentication and Authorization Grants 7. Privacy Considerations
>
> A SAML Assertion may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties,
> should only be transmitted over encrypted channels, such as Transport Layer Security (TLS).  In cases where it is desirable to prevent
> disclosure of certain information to the client, the Subject and/or individual attributes of a SAML Assertion should be encrypted to the
> authorization server.
>
> Deployments should determine the minimum amount of information necessary to complete the exchange and include only that information
> in an Assertion (typically by limiting what information is included in an <AttributeStatement> or by omitting it altogether).  In some cases,
> the Subject can be a value representing an anonymous or pseudonymous user, as described in Section 6.3.1 <https://tools.ietf.org/html/rfc7522#section-6.3.1> of the OAuth Assertion Framework [RFC7521 <https://tools.ietf.org/html/rfc7521>].
>
> -          *RFC 7523 *JSON Web Token (JWT) Profile for OAuth 2.0 Client
> Authentication and Authorization Grants 7.  Privacy Considerations A JWT
> may contain privacy-sensitive information and, to prevent disclosure of
> such information to unintended parties, should only be transmitted
> over encrypted channels, such as Transport Layer Security (TLS).  In
> cases where it is desirable to prevent disclosure of certain information to
> the client,
> the JWT should be encrypted to the authorization server. Deployments
> should determine the minimum amount of information necessary to complete
> the exchange and include only such claims in the JWT.
> In some cases, the "sub" (subject) claim can be a value representing an
> anonymous or pseudonymous user, as described in Section 6.3.1 of
> the OAuth Assertion Framework [RFC7521]. -          *RFC 7591* (OAuth 2.0
> Dynamic Client Registration Protocol) 6.  Privacy Considerations As the
> protocol described in this specification deals almost exclusively with
> information about software and not people, there are very few
> privacy concerns for its use.  The notable exception is the "contacts"
> the developers or other parties responsible for the client software.  These
> values are intended to be displayed to end- users and will be available
> to the administrators of the authorization server.  As such, the
> developer may wish to provide an email address or other contact information
> expressly
> dedicated to the purpose of supporting the client instead of using their
> personal or professional addresses.  Alternatively, the developer may
> wish
> continuing contact and support of the client software after the developer
> moves on and
> someone else takes over that responsibility. In general, the metadata for
> a client, such as the client name and software identifier, are common
> across all instances of a piece of client software
> and therefore pose no privacy issues for end-users. Client identifiers, on
> the other hand, are often unique to a specific instance of a client.
> For clients such as web sites that are used by many users, there may not
> be significant privacy concerns regarding the client identifier, but for
> clients
> device, the client identifier could be uniquely tracked during OAuth 2.0
> transactions
> and its use tied to that single end-user.  However, as the client
> software still needs to be authorized by a resource owner through an OAuth
> 2.0
> authorization grant, this type of tracking can occur whether or not the
> client identifier is unique by correlating the authenticated resource owner
> with
> the requesting client identifier. Note that clients are forbidden by this
> specification from creating their own client identifier.  If the client
> were able to do so, an individual client instance
> could be tracked across multiple colluding authorization servers, leading
> to privacy and security issues. Additionally, client identifiers are
> generally issued
> uniquely per registration request, even for the same instance of software.
> In this way, an application could marginally improve privacy by
> registering
> multiple times and appearing to be completely separate applications.  However,
> this technique does incur significant usability cost in the form of
> requiring
> multiple authorizations per resource owner and is therefore unlikely to be
> used in practice. -          *RFC 7592* (OAuth 2.0 Dynamic Client
> Registration Management Protocol) 6.  Privacy Considerations This
> specification poses no additional privacy considerations beyond those
> described in the core "OAuth 2.0 Dynamic Client Registration Protocol"
> [RFC7591]. -          *RFC 7662 *(OAuth 2.0 Token Introspection) 5.  Privacy
> Considerations The introspection response may contain privacy-sensitive
> information such as user identifiers for resource owners.  When this is
> the case,
> unintended parties.  One method is to transmit user identifiers as opaque
> service-specific
> resource. If the protected resource sends additional information about
> the client's request to the authorization server (such as the client's IP
> considerations that the extension should detail.  However, the nature and
> implications of such
> extensions are outside the scope of this specification. Omitting
> privacy-sensitive information from an introspection response is the
> simplest way of minimizing privacy issues. -          *RFC 7800*
> (Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) 5.  Privacy
> Considerations A proof-of-possession key can be used as a correlation
> handle if the same key is used with multiple parties.  Thus, for privacy
> reasons, it is recommended
> different parties. -          *RFC 8176* (Authentication Method Reference
> Values) 4.  Privacy Considerations The list of "amr" claim values
> returned in an ID Token reveals information about the way that the end user
> authenticated to the identity provider.
> In some cases, this information may have privacy implications. While this
> specification defines identifiers for particular kinds of credentials, it
> does not define how these credentials are stored or protected.
> For instance, ensuring the security and privacy of biometric credentials
> that are referenced by some of the defined Authentication Method Reference
> values is beyond the scope of this specification. -          *RFC 8693*
> (OAuth 2.0 Token Exchange) 6.  Privacy Considerations Tokens employed in
> the context of the functionality described herein may contain
> privacy-sensitive information and, to prevent disclosure
> of such information to unintended parties, MUST only be transmitted over
> encrypted channels, such as Transport Layer Security (TLS).
> Deployments SHOULD determine the minimally necessary amount of data and
> only include such information in issued tokens.  In some cases,
> pseudonymous user. -          *RFC 8705* (OAuth 2.0 Mutual-TLS Client
> Authentication and Certificate-Bound Access Tokens) 8.  Privacy
> Considerations In TLS versions prior to 1.3, the client's certificate is
> sent unencrypted in the initial handshake and can potentially be used by
> third parties
> to monitor, track, and correlate client activity.  This is likely of
> little concern for clients that act on behalf of a significant number of
> end users
> because individual user activity will not be discernible amidst the client
> activity as a whole.  However, clients that act on behalf of a single end
> user,
> such as a native application on a mobile device, should use TLS version
> 1.3 whenever possible or consider the potential privacy implications of
> using mutual TLS on earlier versions. -          *RFC 8707* (Resource
> Indicators for OAuth 2.0) 4.  Privacy Considerations In typical OAuth
> deployments the authorization sever is in a position to observe and track a
> significant amount of user and client behavior.
> It is largely just inherent to the nature of OAuth, and this document does
> little to affect that.  In some cases, however, such as when access token
> 10. 8. 2020 v 19:21, Aaron Parecki <[email-masked]> <[email-masked]>
> :
>
> 
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>