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

[John Carlson]

> On Feb 15, 2016, at 11:06 AM, Leonard Daly <Leonard.Daly at realism.com> wrote:
> 
> 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.
> 
I am speaking of  a JavaScript/X3D integrated application. But we might consider SAML ???

> 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.
> 
As with any reasonable dev environment.  You can control them from going back to the server (edits) and affecting other users unless the user is authorized through a token.

> 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.
> 

Cookies are passed in HTTP, correct?  I am referring to cookies when I speak of session information.  I agree that HTTP does not maintain sessions.  Well, now there are web sockets.  I think the point is, we are not speaking of circuits.  I understand.

> 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.

From Michael Aerator’s post.  New medical applications are being written with OpenID Connect and OAuth2 (FHIR, I believe).  I’m not saying it’s a good idea to put these in JavaScript.  OAuth2 in particular has errata in the standard still.  See: http://docs.smarthealthit.org/  Best practices for authorization, including session id mean using an authorization token (but perhaps not a bearer token — I am not that clear on authorization design at this point).  Releasing an edit token means the user has the authority to change the information on the server when the token is presented back to the server.  Tokens for viewing data are used to provide access to a 3rd party.  This is how a user could provide an H-Anim model from a store to a 3rd party, such as a world. Licensing protects the model.  Technology enables sharing.

Standards help sharing as well.   Do you see a lot of licensing and sharing (possibly for $$) in the 3D world as far as *data*?   That is what I am trying to enable.  Yes, people can rip people off, and go to jail.  Property *should* extend to the virtual medium.  If someone doesn’t want to share they shouldn’t have to.  I’m trying to answer the question of providing a model store where the user doesn’t have to download and upload models, and a store that has agreements with virtual worlds where users can buy content, either from the world, or the virtual store.  That may be external to X3D, but it may be that’s why VR hasn’t taken off too, because there isn’t the equivalent of Facebook for 3D yet.  Perhaps the issue is the ability to create content still?  How are we doing on creating content?  Can a casual user use Blender for anything extensive? I think we’ve got to focus on importing data from cell phones and tablets.   Work with vendors there to produce X3D. I have a Kinect.  Are there good apps for creating 3D on Windows yet?  Can I use Kinect for Windows with Mac OS X yet? Is the following still state of the art? http://blog.mixamo.com/how-to-scan-yourself-into-a-game-ready-3d-model-using-kinect-and-fuse <http://blog.mixamo.com/how-to-scan-yourself-into-a-game-ready-3d-model-using-kinect-and-fuse>

> 
> 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.

I don’t see why 2) is technically not achievable using the url and the load attributes given my previous sentence.

That’s why contracting and licensing were invented.  We need the courts and law to decide.  We have interesting times ahead.

I guess we will see vendors and apps with built in authorization and specific content for it, instead of it being part of a  standard.

In general, with authorization, I am speaking in server side interaction, so it may fall into the bailiwick of SAI and the particular JavaScript engine.  However, I would like to see if we can make it very declarative through the use of fields and attributes.  The server might provide a token as part of the scenegraph that the JavaScript can access.

I general, I would like to see that authorization is not ignored, and thus we end up with applications which handle authorization improperly.  I think the load and url attributes on Inline can work in concert to provide this.  There’s activate on Shaders and enabled on Sensors.  Perhaps it would make sense to collect a document together which *documents* the authorization features of X3D.  I do think that some of the “attributes" *should* be under the control of the casual user, particularly the shader enabling attributes, the user would have to provide a certificate for the shader to access the hardware through the infrastructure of the player, not JavaScript per se.  Anyway, a big tar pit.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160215/e067d2d0/attachment.html>