<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 15, 2016, at 11:06 AM, Leonard Daly <<a href="mailto:Leonard.Daly@realism.com" class="">Leonard.Daly@realism.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="moz-cite-prefix">John,<br class="">
<br class="">
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.<br class="">
<br class=""></div></div></div></blockquote>I am speaking of a JavaScript/X3D integrated application. But we might consider SAML ???</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><div class="moz-cite-prefix">
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.<br class="">
<br class="">
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.<br class="">
<br class=""></div></div></div></blockquote>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.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><div class="moz-cite-prefix">
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.<br class="">
<br class=""></div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><div class="moz-cite-prefix">
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.<br class=""></div></div></div></blockquote><div><br class=""></div>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: <a href="http://docs.smarthealthit.org/" class="">http://docs.smarthealthit.org/</a> 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.</div><div><br class=""></div><div>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? <a href="http://blog.mixamo.com/how-to-scan-yourself-into-a-game-ready-3d-model-using-kinect-and-fuse" class="">http://blog.mixamo.com/how-to-scan-yourself-into-a-game-ready-3d-model-using-kinect-and-fuse</a></div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><div class="moz-cite-prefix">
<br class="">
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<br class="">
i) verifying that task 1 was completed successfully and
appropriately<br class="">
ii) the user has access to item A<br class="">
iii) delivering item A to the client<br class="">
<br class="">
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.</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><div class="moz-cite-prefix">
<br class="">
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.<br class="">
<br class="">
There is no strictly technical solution to protecting content once
released.<br class=""></div></div></div></blockquote><br class=""></div><div>I don’t see why 2) is technically not achievable using the url and the load attributes given my previous sentence.</div><div><br class=""></div><div>That’s why contracting and licensing were invented. We need the courts and law to decide. We have interesting times ahead.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>John</div><br class=""></body></html>