<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">John,<br>
<br>
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>
<br>
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>
<br>
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>
<br>
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>
<br>
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>
<br>
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>
i) verifying that task 1 was completed successfully and
appropriately<br>
ii) the user has access to item A<br>
iii) delivering item A to the client<br>
<br>
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.<br>
<br>
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>
<br>
There is no strictly technical solution to protecting content once
released.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
</div>
<blockquote
cite="mid:5FEB34CF-FF8F-4F03-8EF6-45C8BF8FAAB1@gmail.com"
type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
X3D Co-Chair on Sabbatical<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>