[widgets] OAuth and openID
Hi, I recently spoke to Dan Brickley who raised concerns wrt to using OAuth authentication flows and support open ID. I've only had very limited exposure to these technologies, so I am not the best to comment about how they would work with widgets, but I'm starting this thread so we can discuss ideas. Dan, it would be great if you could outline the problem as you see it? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] The access element (was: RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec)
Hi Mark, 2009/2/19 Priestley, Mark, VF-Group mark.priest...@vodafone.com: Hi All, In the email [1] containing my comments against the LCWD of Widgets 1.0: Packaging Configuration spec, I wrote: 7.10 The access Element The access element defines a network attribute as A boolean attribute that indicates that the widget might need to access network resources as specified in [Widgets-Security]. Based on this description we would like to make the following observations and suggestion: The access element contains security permissions that will be used as hooks in the yet to be written [Widgets-Security] specification. The problem is that the permissions haven't yet been discussed in detail and so we may find that we want to represent additional context other than a black and white is network access required?. For example, it may be the case that it is important from a security point of view to know which bearer or protocol will be used, or to nest a set of domains/URLs with which the widget wants to communicate. I do not have a strong view on what might be relevant here, and I am not suggesting that it needs to be considered as part of the last call of the Packaging and Configuration spec, only that it is likely that the permission will need to be more complex when we look at it from a security perspective. Marcos replied: I think we better start this soon, then. My feeling is that we will need some kind of domain access declarations, and I would like to see them in the configuration document. My follow up: Marcos makes the suggestion that he would like to see the access element replaced/extended with domains. Vodafone have come to a similar conclusion. We feel that a widget author should be able to declare the hosts with which they want to communicate. The widget should then only be allowed to communicate with those hosts. This is beneficial for two reasons: 1.) It allows the widget author to practice the principle of least privilege, limiting the potential attack space Agreed. 2.) It allows other parties (users, widget distributors, consuming widget user agents) to inspect the widget to get some idea of who the widget will communicate with, thereby enabling more sensible security decisions to be made. Agreed. There is however one exception that we would like to enable, the ability for a widget author to indicate that their widget might be expected to communicate with any host. This is to allow for use cases such as widget RSS readers. We would therefore like to propose that the access element is extended along the following lines: access network any-host=true/false target host=somehost.com / target host=en.anotherurl.com / /network /access Firstly, this assumes communication over HTTP. I think we need to make this protocol agnostic. How do I indicate I want to use HTTPs? You would need a special purpose URI parse that can parse malformed URIs. I propose the simpler: access network=true domain href=URI / /access The semantics of the URI can be derived from whatever URI type is used (most likely case will be HTTP, in which case you parse the URI semantics using RFC2616). User agents can support whatever URIs they like, or exclude others (e.g., file://). Declaring network any-host=true/ would mean that regardless of whether the network element contained any child domain elements, the author was declaring that they wanted access to any host (note that by default this value would be false so only authors who wanted access to any host would be inclined to use it). I suggest a special case of domain: domain href=*/ There is IMO an open question as to whether it would better to specify: 1. full URLs in place of hostnames, eg: target url=http://somehost.com; / From my point of view, yes... as per the rationale above. 2. hostnames (to allow for use of http and https and other protocols without requiring multiple declarations), maybe by using an additional attribute, eg: target host=somehost.com protocol=http/ URIs already define all this, so we don't need to break up the URIs into their parts. The semantics of HTTP URIs are well understood and already easily parsed by implementations. 3. hostnames + paths (to allow authors to restrict access to specific resources) target host=somehost.com protocol=http path=/images/ Would be supported by using URIs: domain href=http://somehost.com/images// OR domain href=http://example.com/resource; / The resource could then be exploited (in a good way) at runtime through query strings: script src=http://example.com/resource?callback=helloThere; FWIW, I think we need to look at what CORS is doing with respect to this and mirror as much as we can: http://dev.w3.org/2006/waf/access-control/ Related to the above options is whether or not the omission of protocols and paths could/should be specified to mean any value. This would allow a certain
ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]
ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets] http://www.w3.org/2008/webapps/track/issues/83 Raised by: Mark Priestley On product: Widgets Need to mention somewhere that the digital signature must not be accessible by the start file once the widget is running.
Re: [widgets] Action #224 - Work with Marcos to flesh out the details of the processing model for multiple signatures
2009/2/19 Priestley, Mark, VF-Group mark.priest...@vodafone.com: Hi All, In response to: Action #224 - Work with Marcos to flesh out the details of the processing model for multiple signatures; Mark and Marcos - http://www.w3.org/2008/webapps/track/actions/224 I have outlined two alternative approaches to address the issues that currently exist with the processing of multiple digital signatures (see below). Both approaches need some word-smithing but hopefully they provide a decent starting point for us to agree an approach. FWIW I think I prefer Approach 2. Ok, I like approach 2 too. I'll just make it explicit to pass the signatures list across to the user agent that process the digital signatures. However, something resembling approach 1 will need to go into the Widgets Dig Sig spec. Some things to note. 1. The signed variable of the configuration document is no longer set (and should be deleted). I can't think of anyway to make this variable useful, especially with multiple signatures and the definition of different types of signature. Ok. Gone. 2. The dependency on the Digital Signature spec is nearly completely removed. There is actually one thing that I think needs to be added - how to find the author signature, but otherwise I think we the specifications can be decoupled. Whoa, hold up there! :) Did we reach a resolution that we were going to include a separate author signature? 3. The more I've been thinking about it recently, the more I've come to the conclusion that we should avoid specify anything that equates to a security policy. This is what I have tried to do below, although this does make it necessary to rather obliquely refer to security policies. Agreed. Thoughts and comments welcomed. Thanks, Mark -- Approach 1 -- Step 5 - Process the Digital Signatures Note: The way in which both the author digital signature and distributor digital signature(s) are used is dependent on the security policy implemented by the widget user agent. As such, it is expected that a widget user agent implementing [Widgets-DigSig] will process any digital signatures according to the following algorithm. It is however recognised that a security policy might not require the processing of all of the digital signatures included in the widget package. A widget user agent is therefore able to exit the processing of distributor digital signatures once it has established the information necessary to inform the security decision making process represented by its security policy, eg a signature from a particular end entity has been verified or confirmed as revoked. Exit criteria – A result or set of results from the application of the Procedure for Verifying a Digital Signature Document in the [Widgets-DigSig] to one or more digital signatures that satisfies, positively or negatively, the widget user agents security policy. 1. If present, the widget user agent should apply the Procedure for Verifying a Digital Signature Document, as defined in the [Widgets-DigSig] specification, to the author signature. 2. If the widget user agent determines that an exit criteria has been met: a. If the widget user agent determines that the widget is a valid widget, terminate this algorithm and go to step 6. b. If the widget user agent determines that the widget is an invalid widget, apply the rules for dealing with invalid widgets . 3. Starting with the first file entry in the signatures list; a. Apply the Procedure for Verifying a Digital Signature Document, as defined in the [Widgets-DigSig] specification, to the file entry; b. If the widget user agent determines that an exit criteria has been met: i. If the widget user agent determines that the widget is a valid widget, terminate this algorithm and go to step 6. ii. If the widget user agent determines that the widget is an invalid widget, apply the rules for dealing with invalid widgets, c. Otherwise, select the next file entry in the signatures list and go to 3a in this algorithm. 4. If all of the file entries in signatures have been processed and no exit criteria has been met, go to step 6. -- Approach 2 -- Step 5 - Process the Digital Signatures It is expected that the widget user agent will process the digital signatures in accordance with its security policy. This will involve the widget user agent processing zero or more of the identified digital signatures. I think we should stick to your suggestion and not mention security policies at all in this spec. For this reason, I am excluding the above text. I think we should start mentioning this kind of stuff in
Re: [widgets] Agenda for 19 February 2009 Voice Conference
Hi Mark, 2009/2/19 Priestley, Mark, VF-Group mark.priest...@vodafone.com: Hi Art, c. Action #275 - What is our lifecycle, revocation model?; Mark http://www.w3.org/2008/webapps/track/actions/275 I think this action can be closed - I believe we have agreed that the Widget 1.0: Digital Signatures spec will only cover the format, generation and processing of a digital signatures. Any link to security policy, and therefore lifecycle/revocation models, will now be out of scope (at least for the current specs - might need to be discussed again in the context of the security spec). d. Action #276 - Submit a short set of requirements re extended permissions and parameters and a proposal to address those requirements (to public-webapps); Mark http://www.w3.org/2008/webapps/track/actions/276 I believe this action can also be closed. The initial discussion was around whether the feature element was good enough to represent the types of security sensitive operation that a widget could be expected to carry out. After further discussion, we think that the feature element is good enough - at least in 1.0. This is great to hear. However, if you have any requirements from 2.0, please let us know or please add them to the wiki: http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec
2009/2/16 Priestley, Mark, VF-Group mark.priest...@vodafone.com: No problem. From http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0346.html: [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, or was just named according to the convention for digital signature. Ok, good point. To be abused by an attacker it would either be necessary to inject a reference to the file into the widget, which might be difficult, or to hijack an existing reference to a signature file by swapping the intended signature file for the attacker's signature file (with the same name). While this later attack depends on the author providing such a reference in their widget, there are two reasons why the author may currently choose to do this - to get some information about the signature to display to the user, or possibly more likely, to get around the need to sign everything in their widget resource (I thought of this as a way around signing everything so developers will too!). Ok. It's not a big hole and the attacks require some assistance from developers, but unless there's a reason not to it should be pretty easy to close. I realise that this still requires the ability to read in the file, which would probably have to be via a local Ajax call, not a reference as I suggested above. You could say that it's a pretty theoretical vulnerability but if it's easy to fix and there's no negatives then I think we should address it. Ok, as you saw, I created an issue so we don't forget to address this: http://www.w3.org/2008/webapps/track/issues/83 I also added your description of the hole. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Widgets 1.0 Packaging and Configuration: I18N comments...
Dear i18n WG, Inline comments below and just two quick final questions... On Thu, Jan 29, 2009 at 10:56 PM, Phillips, Addison addi...@amazon.com wrote: Dear Webapps WG, The Internationalization Core WG has reviewed the following document: http://www.w3.org/TR/2008/WD-widgets-20081222/ Here are our comments: 1. In section 7, starting in 7.3 and encompassing each of the text bearing elements that follow, xml:lang is defined as an attribute (good!), but the definition refers to basic language range. I don't believe this is what is intended. The value of xml:lang is a language tag. Ranges are used for selecting which tagged item to display. For example, an item tagged as name xml:lang=pt/ might be selected for display in cases where the default locale is pt-BR. In that example, pt-BR is the range and pt is the value (tag) matching it. Woops! Fixed. 2. Section 7.4 (Widget) The various language bearing elements such as name, description, etc. are of the zero-or-one type. However, it is typically better to allow any number of these elements to occur, provided that none share the same xml:lang. This allows for localization (which is part of the point in allowing xml:lang on the element). We followed Best Practice 12: Working with multilingual documents in Best Practices for XML Internationalization [1], where it says we should have different documents for this kind of localization (to achieve what you propose, we allow multiple configuration documents in a widget). Does i18n core recommend we drop allowing multiple configuration documents and use xml:lang in multiple elements in the manner suggested above? We have built a lot infrastructure around the current model in the spec, so if it's all the same we would prefer to keep it. 3. Section 7.11 (content element). The charset attribute assumes UTF-8 if charset is not present. Note that if the encoding isn't UTF-8, this can almost always be detected reliably and an error can be generated (or some other fallback assumed). Probably the best pattern would be: - if charset is present, use that encoding - if charset is absent, check if it is UTF-8 - if not UTF-8, assume Cp437 (or ISO 8859-1 if that's more appropriate) Done. The section now reads: [[ If the charset attribute is used and the widget start file is not null, then check if the encoding represented by the value of the charset attribute is supported by the user agent. If the encoding is supported, then let the start file encoding be the value of the charset attribute. If the encoding is invalid or unsupported by the user agent then a user agent may use the default encoding (ISO-8859-1) or treat the widget as an invalid widget. Otherwise, the attribute is in error and must be ignored. If the charset attribute was not used and the widget start file is not null, check if the first three bytes of the widget start file match the sequence EF BB BF. If there is a match, then let start file encoding be the value UTF-8. ]] Should we recommend that values for the charset attributes come from the IANA charset registry? http://www.iana.org/assignments/character-sets If so, is there anything we should make implementers and authors aware of? 4. Section 7.15 (ITS tags). Thank you for including ITS support and support for Bidi in particular. Thanks to i18n WG, particularly Felix, for helping us integrate ITS into the spec. Thanks again for taking the time to review our spec! It has been a huge help and it is very much appreciated. We are currently working on revising our i18n model a bit, so we might again need your feedback in the Second Last call. Kind regards, Marcos [1] http://www.w3.org/TR/xml-i18n-bp/#DevMLDoc -- Marcos Caceres http://datadriven.com.au
Re: [widgets] OAuth and openID
Hi Marcos, I'll take a crack at this. OpenID is a technology that authenticates your identity. The cool thing about OpenID is that multiple web sites can share the same identity system, which makes it so that there can be a single mar...@myopenidwhatever.com instead of dozens of separate IDs for you (mar...@google.com, mar...@yahoo.com, etc.). A competitor to OpenID is a login/password screen served by a single web site. With W3C Widgets, you might use OpenID if you have to establish an identity before a widget can be installed; for example, you might have to login to the Apple AppStore (or some other store) before you downloaded a widget from there, and maybe the store supports OpenID. After installation, while a widget runs, the widget (or its server) might periodically need to ask you to enter a login/password to confirm who you are. The login/password software might use OpenID. This might be where Dan sees a problem - OpenID requires browser redirects to do its magic. You might need a list of allowed domains (i.e., at least 2) to support OpenID for this sort of repeated server login. 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. 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. Jon Marcos Caceres marc...@opera.co m To Sent by: public-webapps@w3.org public-webapps-re public-webapps@w3.org qu...@w3.org cc Dan Brickley dan...@danbri.org Subject 02/22/2009 07:11 [widgets] OAuth and openID AM Please respond to marc...@opera.com Hi, I recently spoke to Dan Brickley who raised concerns wrt to using OAuth authentication flows and support open ID. I've only had very limited exposure to these technologies, so I am not the best to comment about how they would work with widgets, but I'm starting this thread so we can discuss ideas. Dan, it would be great if you could outline the problem as you see it? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au inline: graycol.gifinline: pic14024.gifinline: ecblank.gif
