Technologies for Attestation Indications in Collaboration Services

This application is a continuation of U.S. application Ser. No. 18/617,438, filed Mar. 26, 2024, which claims priority to U.S. Provisional Application No. 63/563,272, filed Mar. 8, 2024, each of which is incorporated herein by reference in its entirety.

This application relates to the field of network communications and, in particular, to technologies for attestation indications in collaboration services.

Strong authentication and single sign-on (SSO) technologies provide both enhanced security and user convenience for enterprises. However, even when companies put in place security controls like SSOs, two problems exist. First, attackers with weak or stolen credentials can still access enterprise collaboration platforms, such as audio and video calls or others, and use deepfakes to persuade other users of their authenticity. Second, even when deepfakes are not used, existing content sharing platforms lack effective mechanisms for participants to provide verifiable attestations.

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail.

For the purposes of the present document, the phrases “A/B” and “A or B” mean (A), (B), or (A and B); the phrase “(A)B” means (B) or (A and B), that is, A is optional; and the phrase “based on A” means “based at least in part on A,” for example, it could be “based solely on A” or it could be “based in part on A.”

As briefly introduced above, some environments may allow participation in collaborative platforms with little to no authentication. In these environments, intrusion into an enterprise may be relatively easy to accomplish, and users who are only weakly authenticated may still be visible to others. Applications may not recognize that some users are less authenticated than others. This may be of special concern in communication applications where a deepfake, which may be enabled by convincing audio or video impersonation, can falsely enhance other users' belief in the authenticity of the intruder. Developments in artificial intelligence, machine learning, large language model (LLMs), and stable diffusion have lead to a dramatic increase in the threat to enterprise platforms provided by deepfake attacks.

Embodiments of the present disclosure provide security systems to mitigate these and other threats. For example, some embodiments describe integrating strong authentication with collaborative service platforms. This may be done by providing unforgeable attestations, which may be signed by keys rooted in a hardware root of trust, to a content owner or meeting host and, optionally, to participants of a collaborative service. This may allow the recipients of the attestations to understand and make decisions about a participant's involvement within the collaborative service environment.

1 FIG. 100 100 104 108 112 116 108 104 illustrates a network environmentin accordance with some embodiments. The network environmentmay include a user devicethat provides a device system, collaborative platform client, and an authentication clientcommunicatively coupled with one another via local connections as shown. The device systemmay represent a collection of hardware/software systems on the user deviceto provide various functionality, some of which will be described in further detail herein.

116 120 112 124 112 120 120 116 The authentication clientmay be communicatively coupled with an authentication serverover a network connection. The collaborative platform clientmay be communicatively coupled with a collaborative platform serverover a network connection. In some embodiments, the collaborative platform clientmay additionally be communicatively coupled with the authentication server. However, in some embodiments, device communication with the authentication servermay be handled exclusively by the authentication client.

124 112 124 112 124 120 The collaborative platform serverand collaborative platform clientmay cooperate to provide collaborative services to the user device. Reference to “collaborative platform” may refer to either or both of the collaborative platform serverand the collaborative platform client. The collaborative services may include, but are not limited to, (video/web/tele)conference services, document collaboration services, cloud-based team communication platform services, immersive virtual/augmented reality (AR) services, etc. The collaborative platform servermay include an application programming interface (API) or other interface technology to communicatively couple with the authentication server.

120 116 120 120 116 The authentication serverand the authentication clientmay cooperate to provide authenticated attestations for the purposes of participating in collaborative services provided by the collaborative platform. The authentication servermay be a single sign-on (SSO) or other type of authentication server that provides centralized authentication processes. The authentication serverand authentication clientmay cooperate to obtain attestations from participants of a collaborative service and provide the attestations, or indication thereof, to the collaborative platform.

2 FIG. 2 FIG. 100 100 104 104 104 104 124 204 208 illustrates the network environmentin accordance with some embodiments. The network environmentofincludes two user devices, an administrator device-A and a participant device-P. The administrator device-A may be associated with an administrator of a collaborative service event and the participant device-P may be associated with a participant, or prospective participant, of the collaborative service event. The participant may be a specific user, a group of users, or a location (e.g., a meeting room). The administrator may also be referred to as a host of the event in some instances. The collaborative platform servermay host, or otherwise make available, the collaborative activity/shared contentand may also store a list of participants along with associated attestations.

3 FIG. 300 100 illustrates a signaling diagramfor setup and use of an authenticated collaborative service by components of the network environmentin accordance with some embodiments.

300 104 124 304 124 124 104 124 308 The signaling diagrammay begin with a setup phase in which the administrator device-A sends a sign-up message to the collaborative platform serverat. The sign-up message may initiate a process of creating an account with the collaborative platform server. The account-creation process, which may be specific to the collaborative platform server, may establish a trust relationship between the administrator device-A and the collaborative platform serverat.

104 312 120 316 124 120 124 120 104 124 120 After creating the account and trust relationship, the administrator device-A may, at, add an integration with the authentication server. At, the collaborative platform servermay send a message to the authentication serverto complete the creation of the integration between the collaborative platform serverand the authentication serverto support authentication of collaborative services hosted by the administrator device-A. In some embodiments, the collaborative platform servermay have an API that interfaces with the authentication serverto facilitate the integration and subsequent interactions.

120 104 124 After creating the account and integrating with the authentication server, the signaling flow may advance to a usage phase in which the administrator device-A transmits the message to the collaborative platform serverto initiate a collaborative services session. For example, the administrator may initiate a collaborative activity such as a web meeting or create shared content such as a video.

124 104 324 124 116 116 328 In some embodiments, the collaborative platform servermay, on behalf of the administrator device-A, prompt various entities to provide cryptographically signed attestations about one or more attributes associated with the entities. The entities may be participants, or prospective participants of a meeting. The entities may be a security principal such as, for example, a user, device, or system. The attested attributes may include, for example, user/device/location identity, device/location/system security, or location features. At, the collaborative platform servermay send a request for attestations to the authentication client-P, which may forward the request to an appropriate authentication client-P at.

116 108 332 120 120 The participant devices may use local authentication clients and device systems to fulfill requirements for requested attestations. For example, the authentication client-P may employ the device system-P, using an API, for example, to create and cryptographically sign one or more attestations at. Any of a variety of authentication protocols or algorithms may be used to create/sign attestations. For example, the user may be requested to provide information along with credentials, biometric input, security card, etc. to verify/authentic a source of information. In some embodiments, the attestations may be based on an OpenID Connect (OIDC) in which a user requests, from the authentication server, an authentication challenge. The user may sign the authentication challenge and provide it back to the authentication server, which may then provide an authentication token.

116 116 120 In some embodiments, the authentication client-P may include a hardware component, referred to as a hardware root of trust, for the creation and signing of attestations. The hardware root of trust may be, for example, a trusted platform module (TPM), a secure enclave, a trusted execution environment, etc. The authentication client-P may use APIs of the hardware root of trust to create cryptographic keys and sign attestations with those keys. This may be used to attest to the fact that the attestation's provenance is the hardware root of trust itself. The authentication servermay have the ability to verify those claims by verifying the validity of the signatures associated with the attestations.

In some embodiments, the attestations may be an attestation of authentication, identity, etc. In some embodiments, the attestations may also be associated with a level of assurance. The level of assurance may refer to a level of confidence a system can have in the attested attribute. For example, an authentication attestation may include an authenticator assurance level (AAL) 1 (some confidence), AAL 2 (high confidence), or AAL3 (very high confidence). For another example, an identity attestation may include an identity assurance level (IAL) 1 (some confidence), IAL 2 (high confidence), or IAL3 (very high confidence).

116 332 120 336 116 120 Once created, the cryptographically signed attestations, which may be signed by a cryptographic key rooted in a hardware root of trust, may be provided to the authentication client-P at, which may then be uploaded to the authentication serverat. In the event one or attestations were requested but were not able to be generated successfully, the authentication client-P may provide the authentication serveran indication of the failed attestations. As used herein, reference to an attestation may include a successful attestation or a failed attestation.

300 340 124 120 120 124 The signaling diagrammay further include, at, the collaborative platform serverretrieving the attestations from the authentication server. This may include a request/response or, alternatively, the authentication servermay preemptively send the attestations to the collaborative platform server.

300 344 124 104 116 104 348 The signaling diagrammay further include, at, the collaborative platform serverproviding attestations to the administrator device-A. An authentication client-A at the administrator device-A may verify the cryptographic signature of the attestations, which may then be used to manage the collaborative services session at. For example, the administrator may, based on the received attestations, choose to grant permissions to the participant for participating in the collaborative services session. The permissions may enable/disable/limit a participant's access to aspects of the collaborative services session or shared content therein.

120 116 120 124 124 124 120 124 In some embodiments, verification of the cryptographic signatures of the attestations may be performed by additional/alternative components of the system. For example, the authentication servermay receive the cryptographically signed attestations from the authentication client-P and verify the cryptographic signatures. The authentication servermay then provide a simplified attestation to the collaborative platform serverthat is based on the verification of the cryptographically signed attestations. This may provide the collaborative platform serverwith the desired information without requiring the collaborative platform server, or a downstream component, to have the capabilities of verifying the cryptographic signatures. This may be enabled through a trust relationship established between the authentication serverand the collaborative platform server. In other embodiments, additional/alternative components may perform the verification.

300 208 124 120 208 124 208 120 116 While the signaling diagramdescribes attestations being created in response to the initiation of a collaborative services session, in other embodiments, the creation of the attestations may be separated therefrom. For example, a set of attestations may be obtained from a variety of users and stored in the list of participants with attestationsin the collaborative platform server. In some embodiments, the list may be additionally/alternatively stored in the authentication server. The attestations of the listmay be valid for a period of time and could persist across multiple collaborative services sessions. Thus, when a collaborative services session is initiated, the collaborative platform servermay obtain attestations, associated with (perspective) participants of that session, from the previously acquired attestations from the list. The authentication servermay be responsible for maintaining up-to-date attestations and may periodically query the authentication clients-P accordingly.

4 FIG. 208 illustrates the list of participants with attestationsin accordance with some embodiments. For example, each participant may include one or more attestations. Each attestation may include a number of attributes including, for example, a level of assurance of the attestation, a validity period of the attestation, a time the attestation was acquired, or the hardware provenance associated with the key that created the attestation. In some embodiments, each participant may also various activity attributes that are generated based on the attestations. For example, an activity attribute may include a permissions attribute that describes permissions for participating in a collaborative services session (e.g., enable/disable/limit a participant's access to one or more aspects of the collaborative services session or shared content therein). An activity attribute may also include an authentication strength that provides an indication of how strongly the participant has been authenticated. In some embodiments, the authentication strength may be generated based on the number/type of attestations along with the levels of assurance associated with each attestation. In an instance in which the participant only has one attestation, the authentication strength may correspond to, and be synonymous with, the level of assurance.

In some embodiments, the activity attributes may be automatically generated based on a predefined policy. In some embodiments, the policy may account for a sensitivity setting of the collaborative services session. For example, some sessions may require higher levels of authentication for participation than others. The administrator may have the capability of overriding one or more of the automatically generated activity attributes. In other embodiments, the administrator may generate the activity attributes de novo.

While various embodiments describe the participants as specific users, a participant may also be a device/system that may have a location attribute such as, for example, a meeting room. Attestations associated with a device/system at a meeting room may be derived from a meeting originator, an endorsing party, or security or access-control systems at the location (e.g., biometric data, card readers, motion-detector sensors, etc.).

104 320 In some embodiments, desired attestations may be specific to a collaborative services session. For example, an administrator may desire a first set of attestations for one type of session and a second set of attestations for another type of session. The administrator device-A may establish the attestations desired for a particular session in the account setup phase or the usage phase (e.g., upon initiating the collaborative services session at).

5 FIG. 500 112 In some embodiments, an indication associated with a user's attestations may be provided to one or more participants of a collaborative services session. For example,illustrates a user displaythat may be output by a collaborative platform clientin accordance with some embodiments. In this example, the collaborative services session is generally shown as a videoconference; however, similar concepts may be applied to other types of services.

In this example, the participants of the videoconference may include Host, User 1, User 2, and Room 1. Attestations for each participant may have been obtained in a manner similar to that discussed above. Based on the attestations, the host may be assigned a highest authentication strength (e.g., AS3), User 1 may be assigned the next highest authentication strength (e.g., AS2), Room 1 may be assigned the next highest authentication strength (e.g., AS1), and User 2 may be assigned a lowest authentication strength (e.g., AS0).

112 504 508 512 5 FIG. The collaborative platform clientmay present indications associated with one or more attestations of a participant. For example, the indication may show, or otherwise convey, an authentication strength associated with each of the participants. The indication may be referred to herein as an “AS indication.” The AS indications may include a background (e.g., background), border, or an iconas shown in. In other embodiments, the AS indications may be a watermark or other overlaid feature or a scannable mark. The AS indication may be associated with the participants, as shown in the backgrounds of the participant banner, or to the content contributed by the user, e.g., as shown in the display of User 1's screen.

While the user display 200 shows the AS indications conveying one or more different AS levels, in other embodiments, an AS indications may be binary (for example, either showing presence or absence of a verified attestation). In some embodiments, individual AS indication may be respectively provided for individual participants. In other embodiments, an aggregated AS indication may correspond to more than one participant (e.g., a subset or all of the participants). The aggregated AS indication may be generated based on the individual AS indications. For example, it could be a minimum, maximum, arithmetic, or geometric mean of the individual AS indications. Some embodiments may generate the aggregate AS indication based on the minimum individual AS indications in order to show the potential vulnerability of the group.

Imposing a mandatory display of an authentication strength may allow the participants to confidently identify users/content that may compromised and others that may be trusted.

In some embodiments, the AS indications may provide an indication of whether permissions or authentication strength were provided by the administrator by overriding a predetermined policy. Consider, for example, that the provided attestations for a user are not sufficient to grant the user access to a meeting based on a predetermined policy. If the administrator overrides the policy and admits the user to the meeting, the AS indication may provide an indication that the user has been admitted by an administrative exemption to the policy.

116 In some embodiments, information associated with the authentication strength may be made available to one or more participants. For example, by selecting the indication, a participant may be able to see the attestation details including, for example, specific attestations, levels of assurances, validity period, time acquired, whether an administrative exemption to a policy was granted, etc. In embodiments in which the AS indication is a scannable mark, e.g., quick-response (QR) code, the AS indication may be scanned with a camera of another user device. An authentication client, similar to authentication client, on the scanning device may then display the attestation details for further examination by the user. In the event the AS indication is associated with a video stream, the scannable mark may also enable the user to view a recording of the video stream to inspect historical evidence of the user's authenticity.

In an embodiment in which the collaborative services is a collaborative document, the AS indication may be associated with comments/edits attributed to a user to express a level of authentication that the user had at the time the comment or edit was applied. In instances in which the collaborative platform client/server record user provenance, the authentication server may provide indications of at-the-time authentication strength to facilitate auditing capabilities.

In some embodiments, AS indications, such as a watermark, may be off by default and only affirmatively displayed once proper authentication has been obtained.

In some embodiments, the prominence of the AS indication may be based on the authentication strength associated therewith. For example, AS indications for weakly authenticated users may be the most prominent by, for example, making the indications larger, more visually distinct/colorful, dynamic (e.g., flashing), etc. The AS indications for strongly authenticated users may be less prominent. This may draw focus to the participants/content that has a highest risk of being compromised.

5 FIG. 508 The AS indications may be provided by the collaborative platform to prevent an attacker from presenting a forged AS indication. For example, with respect to, the AS indications may be presented external to the portion of the display that presents the data provided by the users. So, instead of presenting the AS indication in an area of the chart shown on User 1's screen, the AS indication may be placed in the borderor otherwise adjacent to the chart in an area that is provided by the collaborative platform.

In some embodiments, an AS indication such as a watermark or other overlaid feature may be set to always-on-top. This may prevent forgery of the AS indication by changing a background or providing some other manipulation of the in-band data. The AS indication may incorporate obfuscation techniques to resist alteration/removal and may additionally/alternatively allow for personalization through additional information to enhance authenticity evaluation, replay resistance, and traceability. The additional information may include, but is not limited to user information, device information, geolocation information, logos, timestamp/time zone information, etc.

In some embodiments, the AS indication may be generated with a temporal coding system to guard against a replay attack. For example, the AS indication may be generated using a one-time password (OTP) that is valid only for one collaborative services session.

116 104 116 In some embodiments, the AS indication may be updated in real-time to reflect changes in user or device security posture or environmental context. For example, if the authentication client-P of a participant device-P detects a change related to a previously-provided attestation, the authentication client-P may push an update through to the collaborative platform. The collaborative platform may then update the activity attributes (with or without administrator input) and the AS indication accordingly.

In some embodiments, the AS indication may be selectively displayed to a subset of the users. This may be based on a predefined policy or based on a configuration provided by the administrator. The subset of users may be selected based on their authentication strength or some other criteria. In some instances, the other criteria may include whether the user is within a company or organization (e.g., an internal user) or outside of the company or organization (e.g., an external user). An external user may be, for example, a contractor, business partner, client, customer, or prospect. While the challenge of understanding the identity of a peer participant exists for both internal and external users, in some instances, it may be beneficial to only show strong claims to some of the participants and show weak claims to all participants. This may allow the participants to focus scrutiny on the users/content associated with relatively weaker authentications.

6 FIG. 600 is a chartdepicting a selective display of AS indications in accordance with some embodiments. In some instances, AS indications above a threshold (e.g., high authentication strength) may be shown to internal users but not external users, while AS indications below the threshold (e.g., low authentication strength) may be shown to both internal and external users.

600 While chartshows one example with two categories of users/authentication strengths, other examples may include a more granular approach with different types/categories of users and different numbers/types of authentications.

7 FIG. 700 700 124 112 1000 1100 1004 1116 is an operation flow/algorithmic structurein accordance with some embodiments. The operation flow/algorithmic structuremay be performed or implemented by a collaborative platform (e.g., collaborative platform serveror collaborative platform client), device, device/system, or components therein, for example, processorsor.

700 704 The operation flow/algorithmic structuremay include, at, receiving an attestation associated with an entity for participating in a collaborative service. The attestation may be received from an authentication server. The attestation may attest to an identity of the entity, an authentication of the entity or data received from the entity, a posture of a device associated with the entity, an authorization of the entity to access a specific class of information, or a location of the entity. The entity may be a user, device or system. If the entity is has a location attribute such, e.g., a meeting room, the attestation may attest to an identity of one or more users at the location or to aspects associated with a security system at the location.

In some embodiments, the attestation may be a failed attestation in which either no affirmative attestation was received or some part of the authentication process of an affirmative attestation was not successful. A failed attestation may be associated with a lowest level of authentication strength.

700 708 The operation flow/algorithmic structuremay further include, at, providing the attestation associated with the entity to an administrator of the collaborative service. In some embodiments, in response to providing attestation, the collaborative platform may receive an indication of one or more permissions associated with the entity for participating in the collaborative service. The permissions may be provided by the administrator or a predetermined policy.

In some embodiments, the collaborative platform may choose to take into account the hardware root of trust provenance state of the attestation in order to further its trust in the attestation. This may directly or indirectly affect the permissions granted or the authentication strength associated with the attestation.

700 712 The operation flow/algorithmic structuremay further include, at, providing the collaborative service to a number of participants, including the entity associated with the attestation. The collaborative services may be, for example, a (video/web/tele)conference or a collaborative software application.

In providing the collaborative service, the collaborative platform may present data received from the entity to one or more participants of the collaborative services session. The data may include video data or application data. The collaborative platform may also present an indication of the attestation to one or more participants. The indication of the attestation may be a background, icon, watermark, border, or scannable mark that is associated with the presentation of the data.

In some embodiments, the collaborative platform may present additional information associated with the indication of the attestation. The additional information may include, for example, an indication of: a time of receiving the data from the entity; a time of receiving the attestation from an authorization server; a location of the entity when receiving the data from the entity; the provenance of the attestation in terms of the signing key being rooted in a hardware root of trust; or a location of the entity when a signed attestation is created by an authentication client on a device associated with the entity.

In some embodiments, the attestation may be associated with a level of assurance or an authentication strength. The indication of the attestation may be presented in a manner to indicate the level of assurance or authentication strength.

In some embodiments, the indication of the attestation may be presented independent from the data. For example, the indication of the attestation may be presented in a first portion of the user interface, while the data is presented in a second portion of the user interface. As discussed above, this may prevent the user relying on the data to falsely convey the indication of the attestation.

In some embodiments, the data may be overlaid with the indication of the attestation. In this manner, the indication of the attestation may be presented in an always-on-top manner.

In some embodiments, the indication of the attestation may be generated with a temporal code, e.g., an OTP, to mitigate against replay attacks In some embodiments, the one or more participants to which the indication of the attestation is presented may be selected from a number of participants of the collaborative services session. The participants may be selected based on authentication strengths associated with various participants. For example, an indication of a first participant's attestation may be presented to a second participant if the authentication strength associated with the first participant is greater than (or less than) the authentication strength associated with the second participant or some other threshold.

In some embodiments, the collaborative platform may receive an update associated with the attestation. The update may relate to a change in a security posture of a user or device, or a change in an environmental context. The collaborative platform may then generate an updated attestation based on the update and provide an indication of the updated attestation with the data.

8 FIG. 800 800 120 1000 1100 1004 1116 is an operation flow/algorithmic structurein accordance with some embodiments. The operation flow/algorithmic structuremay be performed or implemented by an authentication server, device, device/system, or components therein, for example, processorsor.

800 804 The operation flow/algorithmic structuremay include, at, receiving a cryptographically signed (CS) attestation associated with an entity for participation within a collaborative service. The CS attestation may be received from an authentication client hosted on a device associated with the entity.

The CS attestation may attest to an identity of the entity, an authentication of the entity or data provided by the entity for the collaborative service, a posture of a device associated with the entity, an authorization of the entity to access a specific class of information within the collaborative service, or a location of the entity.

In some embodiments, the CS attestation may be created by a hardware root of trust on the authentication client signing in attestation with a first cryptographic key. In these embodiments, the authentication server may create a second cryptographic key that matches or otherwise complements the first cryptographic key. The authentication server may then verify a validity of the CS attestation based on the second cryptographic key.

800 808 The operation flow/algorithmic structuremay further include, at, providing an attestation based on the CS attestation. The attestation may be provided to a collaborative platform (e. g, collaborative platform server). In some embodiments, the attestation provided to the collaborative platform may be the CS attestation itself, or may be derived from the CS attestation.

In some embodiments, the authentication server may receive an update that is related to the previously provided attestation. The update may relate to a change in a security posture of a user or device, or a change in an environmental context. The authentication server may then transmit the update to the collaborative platform.

9 FIG. 900 900 116 1000 1100 1004 1116 is an operation flow/algorithmic structurein accordance with some embodiments. The operation flow/algorithmic structuremay be performed or implemented by the authentication client, device, device/system, or components therein, for example, processorsor.

900 904 The operation flow/algorithmic structuremay include, at, creating, with a device system, a CS attestation associated with an entity for participation within a collaborative service. The CS attestation may be created in a manner similar to that discussed elsewhere herein.

The CS attestation may attest to an identity of the entity, an authentication of the entity or data provided by the entity for the collaborative service, a posture of a device associated with the entity, an authorization of the entity to access a specific class of information within the collaborative service, or a location of the entity.

900 908 The operation flow/algorithmic structuremay further include, at, providing the CS attestation to an authentication server.

In some embodiments, the authentication client may use the device system to monitor a status of an attestation to detect any changes in a security posture of a user or device, or a change in an environmental context. Based on the monitoring, the authentication client may receive an update that is then transmitted to the authentication server.

10 FIG. 1 9 FIGS.- 1000 1000 1002 1004 1006 1002 1004 1006 1000 is a block diagram of an example computing devicethat can implement the features and processes of(and/or other approaches described herein) in accordance with some embodiments. The computing devicecan include a memory interface, one or more data processors, image processors and/or central processing units, and a peripherals interface. The memory interface, the one or more processorsand/or the peripherals interfacecan be separate components or can be integrated in one or more integrated circuits. The various components in the computing devicecan be coupled by one or more communication buses or signal lines.

1006 1010 1006 1010 Sensors, devices, and subsystems can be coupled to the peripherals interfaceto facilitate multiple functionalities. For example, sensors(e.g., a motion sensor, a light sensor, or a proximity sensor) can be coupled to the peripherals interfaceto facilitate orientation, lighting, and proximity functions. The sensorsmay additionally/alternatively include a global navigation satellite system (GNSS) (e.g., GPS receiver), a temperature sensor, a biometric sensor, magnetometer or other sensing device, to facilitate related functionalities.

1020 1022 1020 1022 A camera subsystemand an optical sensor(e.g., a charged coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) optical sensor) can be utilized to facilitate camera functions, such as recording photographs and video clips, or scanning a QR code. The camera subsystemand the optical sensorcan be used to collect images of a user to be used during authentication of a user (e.g., by performing facial recognition analysis).

1024 1024 1000 1000 1024 1024 Communication functions can be facilitated through one or more wireless communication subsystems, which can include radio frequency receivers and transmitters and/or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the communication subsystemcan depend on the communication network(s) over which the computing deviceis intended to operate. For example, the computing devicecan include communication subsystemsdesigned to operate over various networks. In particular, the wireless communication subsystemscan include hosting protocols.

1026 1028 1030 1026 An audio subsystemcan be coupled to a speakerand a microphoneto facilitate voice-enabled functions, such as speaker recognition, voice replication, digital recording, and telephony functions. The audio subsystemcan be configured to facilitate processing voice commands, voice printing and voice authentication, for example.

1040 1042 1044 1042 1046 1046 1042 1046 The I/O subsystemcan include a touch-surface controllerand/or other input controller(s). The touch-surface controllercan be coupled to a touch surface. The touch surfaceand touch-surface controllercan, for example, detect contact and movement or break thereof using any touch sensitivity technologies, including, but not limited to, capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with the touch surface.

1044 1048 1028 1030 The other input controller(s)can be coupled to other input/control devices, such as one or more buttons, rocker switches, thumbwheel, infrared port, USB port, and/or a pointer device such as a stylus. The one or more buttons (not shown) can include an up/down button for volume control of the speakerand/or the microphone.

1046 1000 1030 1046 In one implementation, a pressing of the button for a first duration can disengage a lock of the touch surface; and a pressing of the button for a second duration that is longer than the first duration can turn power to the computing deviceon or off. Pressing the button for a third duration can activate a voice control, or voice command, module that enables the user to speak commands into the microphoneto cause the device to execute the spoken command. The user can customize a functionality of one or more of the buttons. The touch surfacecan, for example, also be used to implement virtual or soft buttons and/or a keyboard.

1000 In some examples, the computing devicecan present data including application/video/audio data.

1002 1005 1005 1005 The memory interfacecan be coupled to memory. The memorycan include high-speed random-access memory and/or non-volatile memory, such as one or more magnetic disk storage devices, one or more optical storage devices, and/or flash memory (e.g., NAND, NOR). The memorycan store an operating system.

The operating system can include instructions for handling basic system services and for performing hardware dependent tasks. In some examples, the operating system can be a kernel (e.g., UNIX kernel). In some examples, the operating system can include instructions for performing operations described herein.

1005 1005 The memorycan also store communication instructions to facilitate communicating with one or more additional devices, one or more computers and/or one or more servers. The memorycan include graphical user interface instructions to facilitate graphic user interface processing; sensor processing instructions to facilitate sensor-related processing and functions; phone instructions to facilitate phone-related processes and functions; electronic messaging instructions to facilitate electronic-messaging related processes and functions; web browsing instructions to facilitate web browsing-related processes and functions; media processing instructions to facilitate media processing-related processes and functions; GNSS/Navigation instructions to facilitate GNSS and navigation-related processes and instructions; and/or camera instructions to facilitate camera-related processes and functions. and functions.

1005 The memorycan also store other software instructions. In some examples, the media processing instructions are divided into audio processing instructions and video processing instructions to facilitate audio processing-related processes and functions and video processing-related processes and functions, respectively.

1005 1000 Each of the above identified instructions and applications can correspond to a set of instructions for performing one or more functions described above. These instructions need not be implemented as separate software programs, procedures, or modules. The memorycan include additional instructions or fewer instructions. Furthermore, various functions of the computing devicecan be implemented in hardware and/or in software, including in one or more signal processing and/or application specific integrated circuits.

11 FIG. 1100 1100 104 124 120 illustrates a device/systemconfigured to implement techniques described herein in accordance with some embodiments. In some examples, the device/systemmay correspond to user device, collaborative platform server, or authentication server.

1100 1110 The device/systemmay be any type of computing device such as, but not limited to, a server, a mobile phone, a smartphone, a personal digital assistant (PDA), a laptop computer, a desktop computer, a thin-client device, a tablet computer, a wearable device such as a smart watch, an electronic device in a moveable vehicle or transport device, or the like. In some examples, the device/systemmay be in communication with other devices/systems via a network connection.

1100 1114 1116 1116 1116 1100 1106 1116 In one illustrative configuration, the device/systemmay include at least one memoryand one or more processing units (or processor(s)). The processor(s)may be implemented as appropriate in hardware, computer-executable instructions, firmware, or combinations thereof. Computer-executable instructions or firmware implementations of the processor(s)may include computer-executable or machine-executable instructions written in any suitable programming language to perform the various functions described. The device/systemmay also include geo-location devices (e.g., a global positioning system (GPS) device or the like) for providing and/or recording geographic location information associated with the user device. In some examples, the processorsmay include a GPU and a CPU.

1114 1116 1106 1114 1100 1126 1114 The memorymay store program instructions that are loadable and executable on the processor(s), as well as data generated during the execution of these programs. Depending on the configuration and type of the user device, the memorymay be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory). The device/systemmay also include additional removable storage and/or non-removable storageincluding, but not limited to, magnetic storage, optical disks, and/or tape storage. The disk drives and their associated non-transitory computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computing devices. In some examples, the memorymay include multiple different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), or ROM. While the volatile memory described herein may be referred to as RAM, any volatile memory that would not maintain data stored therein once unplugged from a host and/or power would be appropriate.

1114 1126 1114 1126 1100 1106 The memoryand the additional storage, both removable and non-removable, are all examples of non-transitory computer-readable storage media. For example, non-transitory computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. The memoryand the additional storageare both examples of non-transitory computer-storage media. Additional types of computer-storage media that may be present in the device/systemmay include, but are not limited to, phase-change RAM (PRAM), SRAM, DRAM, RAM, ROM, Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital video disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the user device. Combinations of any of the above should also be included within the scope of non-transitory computer-readable storage media. Alternatively, computer-readable communication media may include computer-readable instructions, program modules, or other data transmitted within a data signal, such as a carrier wave, or other transmission. However, as used herein, computer-readable storage media does not include computer-readable communication media.

1100 1128 1100 1100 1130 The device/systemmay also contain communications connection(s)that allow the device/systemto communicate with a data store, another computing device or server, user terminals, and/or other devices via a network. The device/systemmay also include I/O device(s), such as a keyboard, a mouse, a pen, a voice input device, a touch screen input device, a display, speakers, and a printer.

1100 1132 1132 1132 1132 In some embodiments, the device/systemmay also include a hardware (HW) root of trust. The HW root of trustmay be, for example, a TPM, a secure enclave, a trusted execution environment, etc. The HW root of trustmay have APIs that allow an authentication client to access the HW root of trustto create cryptographic keys and sign attestations with those keys.

1114 1114 1112 1111 1113 Turning to the contents of the memoryin more detail, the memorymay include an operating systemand/or one or more application programs or services for implementing the features disclosed herein such as applications(e.g., web applications, clients (e.g., collaborative platform client or authentication client), and engines.

For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, or methods as set forth in the example section below.

In the following sections, further exemplary embodiments are provided.

Example 1 includes a method to be performed by a collaboration platform, the method comprising: receiving, from an authentication server, an attestation associated with an entity for participating in a collaborative service; providing, to an administrator of the collaborative service, the attestation associated with the entity; and providing the collaborative service to one or more participants, wherein the one or more participants includes the entity.

Example 2 includes a method of example 1 or some other example herein, further comprising: receiving, from the administrator, an indication of one or more permissions associated with the entity for participating in the collaborative service.

Example 3 includes method of example one or some other example herein, further comprising: receiving data from the entity; and presenting, as part of the collaborative service, the data and an indication of the attestation to at least one participant of the one or more participants.

Example 4 includes a method of example 3 or some other example herein, wherein the indication of the attestation is a background, icon, watermark, a border, or a scannable mark that is associated with presentation of the data.

Example 5 includes a method of example 3 or some other example herein, further comprising: presenting, with the indication of the attestation, an indication of: a time of receiving the data from the entity; a time of receiving the attestation from the authentication server; a location of the entity when receiving the data from the entity; or a location of the entity when a signed attestation is created by an authentication client on a device associated with the entity, wherein the attestation is the signed attestation or is based on the signed attestation.

Example 6 includes a method of example 3 or some other example herein, wherein the attestation is associated with a level of assurance or an authentication strength and the indication of the attestation is to indicate the level of assurance or the authentication strength.

Example 7 includes a method of example 3 or some other example herein, wherein presenting the data and the indication of the attestation comprises: presenting the indication independent from presenting the data.

Example 8 includes the method of example 7 or some other example herein, further comprising: presenting the indication in a first portion of a user interface; and presenting the data in a second portion of the user interface.

Example 9 includes a method of example 7 or some other example herein, wherein presenting the data and the indication comprises: overlaying the indication on the data.

Example 10 includes the method of example 3 or some other example herein, further comprising: generating the indication of the attestation with a temporal code.

Example 11 includes a method of example 3 or some other example herein, further comprising: determining an authentication strength associated with each of the one or more participants; selecting the at least one participant from the one or more participants based respective authentication strengths; and presenting the indication to the one or more participants based on said selecting the one or more participants.

Example 12 includes a method of example 3 or some other example herein, further comprising: receiving an update associated with the attestation; generating an updated attestation based on the update; and presenting an indication of the updated attestation with the data.

Example 13 includes a method of example 3 or some other example herein, further comprising: presenting the indication all times at which the data is presented.

Example 14 includes a method of example 1 or some other example herein, wherein the collaborative service is a videoconference, teleconference, webconference, or a collaborative software application.

Example 15 includes a method of example 1 or some other example herein, wherein the attestation attests to an identity of the entity, an authentication of the entity or data received from the entity, a posture of a device associated with the entity, an authorization of the entity to access a specific class of information, or a location of the entity.

Example 16 includes a method of example 1 or some other example herein, wherein the entity is a user, a device, or a system.

Example 17 includes a method of example 1 or some other example herein, wherein the entity is a device or system having an attribute of a location and the attestation is to attest to an identity of a user at the location or a security system at the location.

Example 18 includes a method of example 1 or some other example herein, wherein the attestation includes one or more attributes comprising: a level of assurance of the attestation, a validity period of the attestation, a time the attestation was acquired, or a hardware provenance associated with a cryptographic key that created the attestation.

Example 19 includes the method of example 1 or some other example herein, further comprising: determining an authentication strength associated with the attestation is below a predetermined threshold; and restricting permitted operations of the user with respect to the collaborative services based on said determining the authentication strength is below the predetermined threshold. In some embodiments, the presenting of the indication may additionally/alternatively be based on determining the authentication strength is below the predetermined threshold.

Example 20 includes a method of operating an authentication platform, the method comprising: receiving, from an authentication client, a cryptographically signed (CS) attestation associated with an entity for participation within a collaborative service; and providing, to a collaborative platform server, an attestation based on the CS attestation.

Example 21 includes the method of example 20 or some other example herein, wherein the CS attestation attests to an identity of the entity, an authentication of the entity or data provided by the entity for the collaborative service, a posture of a device associated with the entity, an authorization of the entity to access a specific class of information within the collaborative service, or a location of the entity.

Example 22 includes the method of example 20 or some other example herein, wherein the attestation is the CS attestation.

Example 23 includes the method of example 20 or some other example herein, wherein the CS attestation is created by a hardware root of trust on the authentication client signing an attestation with a first cryptographic key and the method further comprises: creating a second cryptographic key that matches or complements the first cryptographic key; and verifying a validity of the CS attestation based on the second cryptographic key.

Example 24 includes a method of operating an authentication client, the method comprising: creating, with a device system, a cryptographically signed (CS) attestation associated with an entity for participation within a collaborative service; and providing, to an authentication server, the CS attestation.

Example 25 includes the method of example 24 some other example herein, wherein the CS attestation attests to an identity of the entity, an authentication of the entity or data provided by the entity for the collaborative service, a posture of a device associated with the entity, an authorization of the entity to access a specific class of information within the collaborative service, or a location of the entity.

Example 26 includes the method of example 24 some other example herein, wherein creating the CS attestations comprises: using a hardware root of trust of the authentication client to create a cryptographic key; and signing an attestation with the cryptographic key to create the CS attestation.

Another example may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1-26, or any other method or process described herein.

Another example may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1-26, or any other method or process described herein.

Another example may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1-26, or any other method or process described herein.

Another example may include a method, technique, or process as described in or related to any of examples 1-26, or portions or parts thereof.

Another example may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-26, or portions thereof.

Another example may include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples 1-26, or portions thereof.

Any of the above-described examples may be combined with any other example (or combination of examples), unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

What is claimed is: