Re: [widgets] OAuth and openID
But one of the major issue with oauth is the fact that is quite impossible to use it outside the browser model. For mobile application, or application without browser, the model is to use your PC to log in, to get a token, and then to put this token in your device. The OAuth rationale is that the user will trust more the browser provider than the application provider. The actual situation, is that it's then impossible to provide a good user experience on constrained device, and I've seen application embeeding some browser just to solve this OAuth issue. It's even worst for non brower based device. As we are moving to the internet of connected device, I personnaly thing that widget are a good way to manage this iternet of connected device, but we still have an issue with authentification which is not yet fully solved with OAuth. On Mon, Feb 23, 2009 at 3:31 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: I agree that postponing any detailed work may be the most pragmatic answer, however oAuth is actually a very important technology for Widgets. oAuth enables a user of an application such as a widget to link that application to an external service, without the application storing, or having access to, any user credentials. For example, using oAuth, a Photo Widget could get access to a user's Flickr account, without the Photo Widget storing the username and credentials of the user, just an authorization token that cannot be reused for any other user or service. To set up the token, the first time the Photo Widget is installed, the user is prompted to go to Flickr, log in there, and agree to grant the widget access to the service. Currently very many widgets store user's account details in widget preferences as this is the only means of user access they have that doesn't involve the user constantly re-entering account details to get at basic functionality. In some environments this may not be a significant risk, depending on how preferences are stored and accessed; however in many cases the fact that a widget can impersonate the user (logging on as the user, rather than with a token) causes issues for trust and auditing. Because many widgets are small local applications offered for remote services that use different user accounts, oAuth is a very important and relevant technology. Which is why, for example, it has been a major task in the oAuth and OpenSocial/Gadgets community to integrate the technology. ((Note also that last I heard oAuth was going to IETF for standardisation)) S On 23 Feb 2009, at 11:02, Thomas Roessler wrote: On 23 Feb 2009, at 05:15, Jon Ferraiolo wrote: OAuth is a technology that authorizes someone to do something. For example, an OAuth server might authorize you to cast a vote in an election. Regarding authorization, in the most common case of W3C Widgets, you would most likely use something like an OMTP/BONDI policy file or some sort of platform-specific (maybe implicit) policy to control authorization instead of OAuth. My thinking is that you can ignore OAuth for now. I think you're conflating policy and protocol here -- OAuth is a way to share an authorization token (and really not much more); it doesn't tell you how to write your authorization policies. If I were on the committee, I would push to finish Widgets 1.0 as quickly as possible, and then put OpenID and OAuth on the list for things to consider for Widgets 1.1. +1 OAuth seems most relevant to XMLHttpRequest level 2, and much less relevant to the widget specs. -- Get the ALL NEW Webwag Mobile - http://webwag.com/mobile Thomas Landspurg - Webwag CTO and Co-founder http://www.webwag.com Tel: +33 6 32 29 42 16
Re: [widgets] Strawman requirements for widget (view/display/window) modes
Hi All, The following draft requirements for display modes were formulated during the F2F based on Mark's strawman proposal (also below). Please feel free to comment. === General Requirements === RXX. Display Modes A conforming specification MUST specify a set of display modes for widgets that stipulate how widgets SHOULD be rendered at runtime when in a specific mode. A conforming specification SHOULD also define particular allowed, or disallowed, user-interaction behaviors for each display mode; such as the ability for a widget to be dragged or re-sized. For each display mode, the way in which the widget is displayed MUST be specified so that the rendering of the Widget is as consistent as possible across widget user agents. The display modes SHOULD also be specified to interoperate with device independence best practices and/or specifications. Proprietary display modes MAY be supported by the Widget User Agent. Rationale: To provide authors with a variety of commonly widget display modes and to help ensure that their widgets are renders as consistently as possible across different Widget User Agents. In addition, allowing proprietary display modes provides a means to support innovative user experiences. ==CONFIGURATION DOCUMENT REQUIREMENT== R.XX Preferred display modes A conforming specification MUST provide a means for author to indicate at least one preferred display mode for a widget. In the absence of a preferred mode, a conforming specification SHOULD provide a consistent default display mode across all user agents. A conforming specification SHOULD make it possible for an author to indicate to the widget user agent which display modes the widget has been designed to run in. The Widget User Agent MAY ignore the indications of display mode supported, but SHOULD NOT ignore the preferred display mode. Rationale: To provide authors a means to indicate a preference over how their widget is initially rendered, though this would not be not guaranteed by the widget user agent. A means of declaring the preferred display mode also provides authors some reassurance, as some widgets may be better suited to being displayed in one display mode over the others. As already stated, widget user Agents may choose to ignore the author's display mode preference, for example, if they do not support the indicated display mode. I don't agree with: A conforming specification SHOULD make it possible for an author to indicate to the widget user agent which display modes the widget has been designed to run in. This should be handled via CSS media queries and handled by the author. ==API AND EVENTS REQUIREMENT=== Rxx Display mode API and Events A conforming specification MUST provide an API to allow authors to programmatically switch between display modes. A conforming user agent MUST be allowed to ignore requests by the author to switch to an unsupported display mode, but MUST throw an exception or error if it will not perform the mode change. A conforming specification MUST also provide a guaranteed means for authors to detect a change in display mode. A conforming specification MUST provide a means for an author to check the current display mode of a widget. ==USER AGENT REQUIREMENT== Rxx. Display Mode Switching A conforming specification MUST allow a widget user agent to dynamically change display mode of a widget. Switching from one mode to another, however, MUST not cause the re-instantiation of the Widget. Furthermore, it MUST be possible for a Widget to seamlessly move between modes, maintaining runtime state and any processes that are in progress. Rationale: To allow a widget user agent to have a degree of control over how widgets are displayed for the purpose of mediating the user experience. For example, the widget user agent my attempt to switch all widgets into floating mode and then display them in a 3D carousel. 2009/2/3 Priestley, Mark, VF-Group mark.priest...@vodafone.com: Hi All, Closing the action 291 (http://www.w3.org/2008/webapps/track/actions/291) please find below a strawman for a set of requirements relating to widget (view/display/window) modes. I have tried to define the requirements without basing them on any of the technical solutions that have been discussed to date. I am in no doubt that the proposed requirements need discussion and refinement - essentially, they are meant only as a starting point. It's over to the group now to agree how best to progress them - I welcome any suggestions on how they could be improved. Thanks, Mark - Strawman Requirement for widget modes - 1. There MUST be a defined set of display modes for a Widget. For each defined display mode, the way in which the Widget is displayed MUST be specified so that the rendering of the Widget is consistent across Widget User Agents. The display modes
Updated Widgets 1.0 Signature editors draft
I've taken a major pass to reorganize and update the Widgets 1.0 Signature specification, taking into account the decision to have author and distributor roles and to no longer mandate Certificate/OCSP/ CRL processing. I also updated and corrected the example and added a section on namespaces as well as other editorial cleanup. http://dev.w3.org/2006/waf/widgets-digsig/ Please take a look and indicate any other proposed changes. We can probably remove editors notes related to Certificates/OCSP/CRL. I have not yet added the file processing rules from the packaging document since we are discussing this item on the mailing list. Thanks regards, Frederick Frederick Hirsch Nokia
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec
The Widget Signature spec is not an API definition so probably does not need to define how signature status information is returned. I also agree that it would be incorrect to define in the Widget Signature spec whether or not a widget is valid, that is out of scope. The spec limits itself to signature validation. However I would not want to be prescriptive in the specification to the level of status return codes. We may want to add a security considerations note along the lines of As distributor signatures are not included in an overall widget signature, it is possible for signatures to be added or removed and hence a secure channel for widget delivery might be preferable. regards, Frederick Frederick Hirsch Nokia On Feb 6, 2009, at 10:51 AM, ext Priestley, Mark, VF-Group wrote: Hi Marcos, More responses to your comments below (marked [mp]). Still need to get back to you on the access element but I need to think about it a bit more first. Thanks, Mark -- Step 5 Process the Digital Signatures We disagree with the stage 2, specifically If the file entry is deemed by the [Widgets-DigSig] to be an invalid widget, then a widget user agent must treat this widget as an invalid widget., on two grounds: (1) Because one signature is invalid it doesn't mean that all of the signatures are invalid; (2) Just because one signature or all signatures are invalid does not mean that the widget should not be installed, only that it should _not_ be treated as a signed widget. The security policy of the device might be configured not to install an unsigned widget or a widget with an invalid signature but this should be dependent on the security policy implemented. Sorry, I think you might have misunderstood what I was trying to say here (probably I did not write it clearly enough). This assertion is here to deal with instances where the digital signature deemed by the Widgets Dig Sig spec to be somehow fully broken or completely non-conforming in such a way that all processing must stop. I don't yet know if Widgets Dig Sig will spit out such a result for any digsig it is processing, but it seemed like a good idea to put this in here at the time. [mp] No this was pretty much my understanding. Maybe my comment wasn't clear enough... IMO [Widgets-DigSig] should result in a list of signature status values. How the widget user agent responds to those values should be dependent on the security policy of the widget user agent. In other words, this is something that is controlled by the Widgets Dig Sig spec. If it turns out that Widgets Dig Sig never results in an invalid widget situation, then I will take this out. I've created a red note in the spec that says Issue: [Widgets-DigSig] may never identify a widget package as invalid as a reminder that we need to sort this out. [mp] Well I would argue that the [Widgets-DigSig] will never identify a widget package as invalid although it may decide that one or more signature(s) are invalid. The security policy of the device may decide that the widget shouldn't be installed based on the result of processing the signature file(s) but that is a different thing. I think that best we can do in the PC spec is say whether or not the widget is signed (and even this could be tricky). FWIW, I think step 5 is buggy and needs a rewrite (I've added another issue to the spec stating as such). I'll need to work with you to fix it as we progress the Dig Sig spec. [mp] I'll be available to work on this next week --- Step 4 Locate Digital Signatures for the Widget I'm not sure whether the packaging and configuration specification is the correct place to do this but IMHO there needs to be a statement that a files with a file name corresponding to the naming convention for digital signatures are not accessible from the widget once the widget is installed / instantiated. Failure to impose this restriction will make it possible to include a signature and then reference it from the signed code, which presents a security hole. Good point. This seems like something that needs to be in the yet to be written a widget runtime security spec. I've added an issue note to the spec so we don't forget about this. Just out of interest, can you present the nature of the security hole? i.e., once an attacker has the signature, say, via an XSS attack, what could they do with it? [mp] The hole is that signature files are excluded from the generation of the signature values in any other signature files. This means that if, for example, an attacker added to the widget resource a signature file containing some malicious content, the malicious content of that file wouldn't be covered by any of the other signatures but the widget user agent thinks the entire widget resource is signed. This could happen regardless of whether or not the signature file was actually valid,
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec
Hi Frederick, On Tue, Feb 24, 2009 at 11:19 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: The Widget Signature spec is not an API definition so probably does not need to define how signature status information is returned. You are right, so agreed. I also agree that it would be incorrect to define in the Widget Signature spec whether or not a widget is valid, that is out of scope. Right again. The spec limits itself to signature validation. However I would not want to be prescriptive in the specification to the level of status return codes. Ok, makes sense. We may want to add a security considerations note along the lines of As distributor signatures are not included in an overall widget signature, it is possible for signatures to be added or removed and hence a secure channel for widget delivery might be preferable. Ok, that is also an important security consideration. Should definitely have that in the spec under security considerations or some such section. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property
+1, I think the current Widget Signature draft reflects this point of
view with the focus on author and distributor signatures and no usage
or concern with updates specific to Widget Signature. That said, we
may wish to review the update mechanism from a security point of view,
but I don't believe that is specific to Widget Signature.
regards, Frederick
Frederick Hirsch
Nokia
On Feb 13, 2009, at 8:26 AM, ext Marcos Caceres wrote:
2009/2/12 Priestley, Mark, VF-Group mark.priest...@vodafone.com:
[mp] As a general comment, I think this is a pretty difficult
problem to address in a secure manner. IMO the most reliable way of
authorising an update would be through the use of an update
signature however, HTTPS provides a workable alternative and plain
HTTP might be fine in other circumstances. For what it's worth I
think that the real security issue is how the update is handled but
this doesn't mean defining an update signature is not useful.
I agree that an update signature would be useful, but would like to
see this just be solved with HTTP and HTTPS for v1. That should cover
most use cases.
Here is my current thinking. Widget version 1 is distributed and
signed. The config looks like this:
widget version=1.0
update href=https://some.com/update?version=1.0; /
/widget
Because the widget was signed, the update href can be considered
authoritative/trusted. That securely downloads the update description
document:
widgetupdate xmlns=http://www.w3.org/ns/widgets;
src=https://example.com/myWidget/v1.1b/awesome.wgt;
version=1.1
id=http://example.com/myWidget;
size=1024
notify=https://example.com/myWidget/updateManager.php?this-v=1.1amp;was-v=
{version}
details href=http://a.com/myWidget/1.1/whatsnew;
We fixed some bugs and improved performance!
/details
/widgetupdate
The src is downloaded and treated as a normal widget package. If it is
not signed, or the signature cannot be validated, then the usual
warnings are given. If it is signed, then it is processed as normal.
Is there much wrong with the current model?
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Re: [selectors-api] LCWD comments
Yes, I'm satisfied with all the changes (although I still think it's useless and a bit risky of minor discrepancies to define document order when DOM Level 3 Core is already normatively referenced), thank you for being so responsive and for the entirety of your effort on this spec. This makes me even more sorry to have misled you (as you probably already know, since the issue is mentioned in e.g. http://lists.w3.org/Archives/Public/www-svg/2008Dec/0039.html) by asking to write document where the text should read DOM. (D does stand for Document, but in fact there needn't be one. I tend to repeatedly forget that it's an API spec, not a CSS module. And it's perfectly useful for trees rooted at detached Element or DocumentFragment nodes.) Could you, please, revert this one change? On the other hand, I won't object either if the concerned fragment (the document tree or subtree in question) is left as is. After all, this is how most of your commenters at www-...@w3.org express these same concepts, with no big shadow of confusion within sight.
