[x3d-public] X3D and Authorization (OAuth2 anyone?)

[Leonard Daly]

John,

The authorizations you list below are a huge mixed bag. They include 
in-application authorizations (wall collisions, skill levels features, 
etc.), application/server interactions (download levels), server-side 
privileges (uploads), and things that fit into multiple areas, including 
items not mentioned (e.g., medical records). In the last category, the 
application system developer needs to ensure that the records have the 
proper traceability, and external features (e.g., printing) are controlled.

X3D was designed to be on the tail end of a long chain for viewing of 
information. There are some features of the SAI (e.g., getX3dFromUrl) 
that can be used to communicate back to a server, but there are no 
specific capabilities offered that implement any of these. HTTPS 
(Networking Level 4) is not even required until the Full profile.

Some of the items listed below (1 and 3) cannot be controlled if the X3D 
code is fully in JavaScript. A debugger can be turned on and the fields 
that limit certain capabilities can be modified to allow them.

The comment about using HTTP session information is wrong. HTTP is a 
state-less protocol. The only session information is one created by the 
application on the server. The server application typically passes one 
or more cookies that contain a session ID that allows the server 
application to maintain a state. If the server application does not 
create and maintain the session, there is not useful information.

All recent applications that maintain session are built this way. Much 
of this type of structure is required for dealing with credit card 
transactions. Medical application (once the user is Authenticated and 
Authorized) work this way. Some of these mechanisms are mandated by law 
or contract, the details are typically handled through best practices in 
building secure applications.

Secure applications will not put items into JavaScript that the user 
does not have access. If getting access to item A requires doing task 1 
first, then after task 1 is completed, the client will send an AJAX 
message to the server with justification that task 1 was completed and 
request item A. The server is responsible for
i) verifying that task 1 was completed successfully and appropriately
ii) the user has access to item A
iii) delivering item A to the client

Much of this work is already addressed (just not in X3D). I also don't 
think that the Consortium has enough people with knowledge, interest, 
and available time to pursue X3D-external security. In-application 
security, meaning maintaining the integrity of the application is a 
useful topic for a Consortium effort. It should not be part of H-Anim 
because there are many applications where H-Anim is not used, but the 
integrity of the application is important.

I think a more important issue is addressing how to maintain access 
controls over 3D models. The typical response for anything web-related 
is that don't release anything from the server important that you have 
no means to protect. Once it has been released from the server, you (as 
the provider) need to assume that it can be released to the world. To 
prevent this, there is usually some sort of legally binding agreement 
that makes it in the client's best interest to protect the information. 
I suspect the results of such an effort would be to establish best 
practices in creating the information for release (content resolution, 
water marking, etc.) and tools to help enable that.

There is no strictly technical solution to protecting content once released.


Leonard Daly




> I am wondering how people use X3D and Authorization and whether we need a Working Group focused on Authorization as a subsection of the Security Working Group.  A typical X3D application has no need for authorization. I can imagine several uses for Authorization:
>
> 1.  Physics and collision detection.  One does not have the authority to walk through walls.
> 2.  Authorizing the downloading of game levels or rooms from the server.  I can imagine JavaScript setting an authorization token in the Inline url so the url will be downloaded.
> 3.  Authorizing the insertion, movement, viewing and deletion of parts of the scenegraph.  This include locking down physics.  The "ground" cannot move.  The sun doesn’t disappear from the sky in 1 second.  Gravity applies.
> 4.  Authorizing uploads of user information.
> 5.  Authorizing the use of shaders with reasonable fallbacks.
> 6.  Authorizing the use of items once the user has reached a certain skill level (tutorials, menus).
> 7.  Authorizing the  reading and modification and archiving of EMRs (electronic medical records) and portions of EMRs (3D images).
> 8.  Authorizing the purchase of “in game” items with the user’s credit card (mobile) or account.
>
> I am also wondering if using OAuth2 is a reasonable way to implement Authorization of this type of thing.  If a user wants to do an operation, the X3D application presents the request to an Oauth2 server which looks under the user's account to see if that authority has been granted to the X3D application or user by a server (for other users) or the user (for the main user).  These permissions may be preloaded into the X3D application to do stuff like grey out menus or preload the physics engine.
>
> Many of these things can be programmed into an application by hand.  One advantage of abstracting them away from the application is you can define  user profiles that work across many applications.
>
> So perhaps we should start on developing a profile of the user that can be shared across apps?  Is this part of H-Anim?
>
> Can someone think of other authorizations that might come in handy?
>
> I recall one time asking this question and I got back the response, HTTP session information is all we need.  Is this still the case?
>
> Does Authentication play any role other than getting a list of permissions or authorities for the application?
>
> Thanks,
>
> John
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
X3D Co-Chair on Sabbatical
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160215/5f765d76/attachment.html>