Microsoft is so concerned about the future of cloud computing thatit's urging the government to step in. In a speech Wednesday[2010-01-20], Microsoft general counsel and senior vice presidentBrad Smith called on government and business to shore up confidencein cloud computing by tackling issues of privacy and security -- twomajor concerns that have been voiced about the cloud...
A Microsoft survey found that 58 percent of the public and 86 percentof business leaders are excited about the possibilities of cloudcomputing. But more than 90 percent of them are worried about security,availability, and privacy of their data as it rests in the cloud.Microsoft said it also found that most of the people surveyed believethe U.S. should set up laws and policies to govern cloud computing...
During his speech, Smith proposed that Washington create a CloudComputing Advancement Act that would protect consumers and give thegovernment tools to handle issues such as data privacy and security.He added that an international dialogue is crucial in addressing datasecurity so that information is protected no matter where it resides.In proposing legislation, Microsoft is looking to the government toenact specific measures, including to: (1) Beef up the ElectronicCommunications Privacy Act to more clearly define and protect theprivacy of consumers and businesses; (2) Update the Computer Fraud andAbuse Act so that law enforcement has the resources it needs to combathackers; (3) Establish truth-in-cloud-computing principles so thatconsumers and businesses know how their information will be accessedand secured; (4) Set up a framework so that differences in regulationson cloud computing among various countries can be better clarifiedand reconciled... More Info
Friday, January 22, 2010
IETF Internet Draft on Web Linking Considered as a Proposed Standard
The Internet Engineering Steering Group (IESG) announced receipt of aa request to consider version -07 of the "Web Linking" specificationas an IETF Proposed Standard. The IESG plans to make a decision in thenext few weeks, and solicits final comments on this action through2010-02-17.
This document specifies relation types for Web links, and defines aregistry for them. It also defines the use of such links in HTTP headerswith the Link header-field.
Background: "A means of indicating the relationships between resourceson the Web, as well as indicating the type of those relationships, hasbeen available for some time in HTML, and more recently in Atom (IETFRFC 4287). These mechanisms, although conceptually similar, are separatelyspecified. However, links between resources need not be format-specific;it can be useful to have typed links that are independent of theirserialisation, especially when a resource has representations inmultiple formats. To this end, this document defines a framework fortyped links that isn't specific to a particular serialisation orapplication. It does so by re-defining the link relation registryestablished by Atom to have a broader domain, and adding to it therelations that are defined by HTML.
Appendix E (Document History) in this 25-page document lists some sixteen(16) changes since the publication of version -06 (20 pages): Allowedmultiple spaces between relation types; Relaxed requirements forregistered relations; Removed Defining New Link Serialisations appendix;Added Field registry; Added registry XML format; Changed registrationprocedure to use mailing list(s), giving the Designated Experts moreresponsibility for the smooth running of the registry; Loosened prohibitionagainst media-specific relation types to SHOULD NOT; Disallowedregistration of media-specific relation types -- can still be used asextension types; Clarified that parsers are responsible for resolvingrelative URIs; Fixed ABNF for extended-initial-value; Fixed 'title*'parameter quoting in example; Added notes for registered relations thatlack a reference; Added 'hreflang' parameter; Clarified status of 'rev';Removed advice to use '@profile' in HTML4; Clarified what multiple'*title' and 'hreflang' attributes mean... More Info
This document specifies relation types for Web links, and defines aregistry for them. It also defines the use of such links in HTTP headerswith the Link header-field.
Background: "A means of indicating the relationships between resourceson the Web, as well as indicating the type of those relationships, hasbeen available for some time in HTML, and more recently in Atom (IETFRFC 4287). These mechanisms, although conceptually similar, are separatelyspecified. However, links between resources need not be format-specific;it can be useful to have typed links that are independent of theirserialisation, especially when a resource has representations inmultiple formats. To this end, this document defines a framework fortyped links that isn't specific to a particular serialisation orapplication. It does so by re-defining the link relation registryestablished by Atom to have a broader domain, and adding to it therelations that are defined by HTML.
Appendix E (Document History) in this 25-page document lists some sixteen(16) changes since the publication of version -06 (20 pages): Allowedmultiple spaces between relation types; Relaxed requirements forregistered relations; Removed Defining New Link Serialisations appendix;Added Field registry; Added registry XML format; Changed registrationprocedure to use mailing list(s), giving the Designated Experts moreresponsibility for the smooth running of the registry; Loosened prohibitionagainst media-specific relation types to SHOULD NOT; Disallowedregistration of media-specific relation types -- can still be used asextension types; Clarified that parsers are responsible for resolvingrelative URIs; Fixed ABNF for extended-initial-value; Fixed 'title*'parameter quoting in example; Added notes for registered relations thatlack a reference; Added 'hreflang' parameter; Clarified status of 'rev';Removed advice to use '@profile' in HTML4; Clarified what multiple'*title' and 'hreflang' attributes mean... More Info
Heartland Moves To Encrypted Payment System
"Responding to its widely reported and massive data breach that tookplace a year ago, Heartland Payment Systems will be moving to anend-to-end encryption system for payment transactions, according toChairman and CEO Robert Carr: 'We're using encryption on the front endto keep card numbers out of our merchants' systems, and to also haveall the card numbers coming through our network be encrypted throughout,except at the point of decryption'. In January 2009, Heartland PaymentSystems reported that it found that intruders had penetrated its systemsand planted software to harvest card numbers, using SQL injectionattacks to plant programs inside the network that would sniff the cardnumbers.
Heartland, which handles more than 4 billion transactions annually formore than 250,000 merchants, will be using Thales nShield Connecthardware security module along with Voltage Security's SecureDataencryption software as the basis of this capability... This new systeminvolves installing a tamper-resistant security module (TRSM) at thepoint-of-sale system. When a card is swiped, the TRSM encrypts thecard's number with a public key using Identity Based Encryption, andit is sent to the Heartland gateway. This new system will offermerchants the capability to encrypt cards so the merchant themselveswill not house the card numbers on their systems at all, explainedTerrence Spies, the chief technology officer for Voltage Security. Mostmerchant payment-processing systems encrypt the PIN number or securitynumbers of cards. The card numbers themselves aren't typically encryptedat the cash registers, also called point-of-sale systems.
Spies: "The HSM controls the process of decrypting the private key...This system will use a technique called format-preserving encryption(FPE), which means the encrypted numbers will be the same length asthe original card numbers, allowing the encrypted numbers to be usedin other database systems as identifiers, rather than the originalnumbers. Heartland piloted a few test systems with merchants last yearand now plans to start offering the service to all its customers.Because moving to the card encryption will require purchasing newhardware for the register, Heartland will offer the end-to-end encryptionas an opt-in... Carr said that if the merchant implements the systemcorrectly and it then suffers a breach involving the leakage of cardnumbers, then Heartland will assume the liability for the breach..." More Info
Heartland, which handles more than 4 billion transactions annually formore than 250,000 merchants, will be using Thales nShield Connecthardware security module along with Voltage Security's SecureDataencryption software as the basis of this capability... This new systeminvolves installing a tamper-resistant security module (TRSM) at thepoint-of-sale system. When a card is swiped, the TRSM encrypts thecard's number with a public key using Identity Based Encryption, andit is sent to the Heartland gateway. This new system will offermerchants the capability to encrypt cards so the merchant themselveswill not house the card numbers on their systems at all, explainedTerrence Spies, the chief technology officer for Voltage Security. Mostmerchant payment-processing systems encrypt the PIN number or securitynumbers of cards. The card numbers themselves aren't typically encryptedat the cash registers, also called point-of-sale systems.
Spies: "The HSM controls the process of decrypting the private key...This system will use a technique called format-preserving encryption(FPE), which means the encrypted numbers will be the same length asthe original card numbers, allowing the encrypted numbers to be usedin other database systems as identifiers, rather than the originalnumbers. Heartland piloted a few test systems with merchants last yearand now plans to start offering the service to all its customers.Because moving to the card encryption will require purchasing newhardware for the register, Heartland will offer the end-to-end encryptionas an opt-in... Carr said that if the merchant implements the systemcorrectly and it then suffers a breach involving the leakage of cardnumbers, then Heartland will assume the liability for the breach..." More Info
Open Source Clouds on the Rise
"Cloud computing has the potential to transform how government agenciestap into IT services, and open source is an underlying technology inseveral of the early government clouds that have been developed... Achallenge for government agencies is determining how one cloud can workwith other clouds and IT systems to provide the same secure, robustinfrastructure that exists with traditional IT environments. Here'swhere agencies may turn to open source, which has the advantage of'openness,' providing flexibility, interoperability, and the potentialfor customization without the risks of vendor lock-in...
Components of the open source software stack that are being used tobuild and manage clouds include the Linux operating system, Eucalyptus(incorporates the Apache Axis2 Web services engine, Mule enterpriseservice bus, Rampart security, and Libvirt virtualization), Datacloud,Nimbus' EC2 interface (lets organizations access public cloudinfrastructures), virtual machine hypervisors, and Zend Technologies'Simple API (can be used for calling a cloud service from multiple clouds;GoGrid, IBM, Microsoft, Nirvanix Storage Delivery Network, and RackspaceFiles all support it).
In an example of how the pieces fit together, NASA's Ames Research Centeris using Eucalyptus, the Lustre file system, Django Web applicationframework, and SOLR indexing and search engine in its Nebula cloud.Standards are still needed to ensure the viability of open source clouds,and reliability and security have to be proven. With those concerns onthe table, the gradual adoption of cloud computing, along with opensource, is the path we're on. Open source can help minimize up-frontinvestment, give agencies control over their clouds, and tap into sharedresources..." More Info
Components of the open source software stack that are being used tobuild and manage clouds include the Linux operating system, Eucalyptus(incorporates the Apache Axis2 Web services engine, Mule enterpriseservice bus, Rampart security, and Libvirt virtualization), Datacloud,Nimbus' EC2 interface (lets organizations access public cloudinfrastructures), virtual machine hypervisors, and Zend Technologies'Simple API (can be used for calling a cloud service from multiple clouds;GoGrid, IBM, Microsoft, Nirvanix Storage Delivery Network, and RackspaceFiles all support it).
In an example of how the pieces fit together, NASA's Ames Research Centeris using Eucalyptus, the Lustre file system, Django Web applicationframework, and SOLR indexing and search engine in its Nebula cloud.Standards are still needed to ensure the viability of open source clouds,and reliability and security have to be proven. With those concerns onthe table, the gradual adoption of cloud computing, along with opensource, is the path we're on. Open source can help minimize up-frontinvestment, give agencies control over their clouds, and tap into sharedresources..." More Info
W3C First Public Working Draft for Selectors API Level 2
Members of the W3C Web Applications Working Group have published a FirstPublic Working Draft for the specification "Selectors API Level 2."Selectors, which are widely used in Cascading Style Sheets (CSS), arepatterns that match against elements in a tree structure...
The Selectors API specification defines methods for retrieving Elementnodes from the DOM by matching against a group of selectors, and fortesting if a given element matches a particular selector. It is oftendesirable to perform DOM operations on a specific set of elements ina document. These methods simplify the process of acquiring and testingspecific elements, especially compared with the more verbose techniquesdefined and used in the past...
Implementors should be aware that this specification is not stable.Implementors who are not taking part in the discussions are likely tofind the specification changing out from under them in incompatible ways.Vendors interested in implementing the specification before iteventually reaches the Candidate Recommendation stage should join theappropriate mailing lists and take part in the discussions..." More Info
The Selectors API specification defines methods for retrieving Elementnodes from the DOM by matching against a group of selectors, and fortesting if a given element matches a particular selector. It is oftendesirable to perform DOM operations on a specific set of elements ina document. These methods simplify the process of acquiring and testingspecific elements, especially compared with the more verbose techniquesdefined and used in the past...
Implementors should be aware that this specification is not stable.Implementors who are not taking part in the discussions are likely tofind the specification changing out from under them in incompatible ways.Vendors interested in implementing the specification before iteventually reaches the Candidate Recommendation stage should join theappropriate mailing lists and take part in the discussions..." More Info
OASIS Public Review Draft for Production Planning and Scheduling (PPS)
Members of the OASIS Production Planning and Scheduling (PPS) TechnicalCommittee have released an approved set of PPS specifications forpublic review through March 12, 2010. This TC was chartered in 2003to "develop common object models and corresponding XML schemas forproduction planning and scheduling software, which can communicate witheach other in order to establish collaborative planning and schedulingon intra and/or inter enterprises in manufacturing industries."
"OASIS PPS (Production Planning and Scheduling) specifications deal withproblems of decision-making in all manufacturing companies who want tohave a sophisticated information system for production planning andscheduling. PPS specifications provide XML schema and communicationprotocols for information exchange among manufacturing applicationprograms in the web-services environment...
"PPS (Production Planning and Scheduling) Part 1: Core Elements, Version1.0" focuses on an information model of core elements which can be usedas ontology in the production planning and scheduling domain. Since theelements have been designed without particular contexts in planning andscheduling, they can be used in any specific type of messages as abuilding block depending on the context of application programs.
"PPS (Production Planning and Scheduling) Part 2: Transaction Messages,Version 1.0" focuses on transaction messages that represent domaininformation sending or receiving by application programs in accordancewith the context of the communication, as well as transaction rules forcontexts such as pushing and pulling of the information required..."PPS (Production Planning and Scheduling) Part 3: Profile Specifications,Version 1.0" focuses on profiles of application programs that may exchangethe messages. Application profile and implementation profile are defined.Implementation profile shows capability of application programs in termsof services for message exchange, selecting from all exchange itemsdefined in the application profile. The profile can be used fordefinition of a minimum level of implementation of application programswho are involved in a community of data exchange..." More Info
"OASIS PPS (Production Planning and Scheduling) specifications deal withproblems of decision-making in all manufacturing companies who want tohave a sophisticated information system for production planning andscheduling. PPS specifications provide XML schema and communicationprotocols for information exchange among manufacturing applicationprograms in the web-services environment...
"PPS (Production Planning and Scheduling) Part 1: Core Elements, Version1.0" focuses on an information model of core elements which can be usedas ontology in the production planning and scheduling domain. Since theelements have been designed without particular contexts in planning andscheduling, they can be used in any specific type of messages as abuilding block depending on the context of application programs.
"PPS (Production Planning and Scheduling) Part 2: Transaction Messages,Version 1.0" focuses on transaction messages that represent domaininformation sending or receiving by application programs in accordancewith the context of the communication, as well as transaction rules forcontexts such as pushing and pulling of the information required..."PPS (Production Planning and Scheduling) Part 3: Profile Specifications,Version 1.0" focuses on profiles of application programs that may exchangethe messages. Application profile and implementation profile are defined.Implementation profile shows capability of application programs in termsof services for message exchange, selecting from all exchange itemsdefined in the application profile. The profile can be used fordefinition of a minimum level of implementation of application programswho are involved in a community of data exchange..." More Info
OAuth Web Resource Authorization Profiles
IETF has published an Internet Draft for "OAuth Web ResourceAuthorization Profiles." The OAuth Web Resource Authorization Profiles(OAuth WRAP) allow a server hosting a Protected Resource to delegateauthorization to one or more authorities. An application (Client)accesses the Protected Resource by presenting a short lived, opaque,bearer token (Access Token) obtained from an authority (AuthorizationServer). There are Profiles for how a Client may obtain an Access Tokenwhen acting autonomously or on behalf of a User.
Background: "As the internet has evolved, there is a growing trend fora variety of applications (Clients) to access resources through an APIover HTTP or other protocols. Often these resources require authorizationfor access and are Protected Resources. The systems that are trustedto make authorization decisions may be independent from the ProtectedResources for scale and security reasons. The OAuth Web ResourceAuthorization Profiles (OAuth WRAP) enable a Protected Resource todelegate the authorization to access a Protected Resource to one ormore trusted authorities.
Clients that wish to access a Protected Resource first obtainauthorization from a trusted authority (Authorization Server). Differentcredentials and profiles can be used to obtain this authorization, butonce authorized, the Client is provided an Access Token, and possiblea Refresh Token to obtain new Access Tokens. The Authorization Servertypically includes authorization information in the Access Token anddigitally signs the Access Token. Protected Resource can verify thatan Access Token received from a Client was issued by a trustedAuthorization Server and is valid. The Protected Resource can thenexamine the contents of the Access Token to determine the authorizationthat has been granted to the Client.
The Access Token is opaque to the Client, and can be any format agreedto between the Authorization Server and the Protected Resource enablingexisting systems to reuse suitable tokens, or use a standard tokenformat such as a Simple Web Token or JSON Web Token. Since the AccessToken provides the Client authorization to the Protected Resource forthe life of the Access Token, the Authorization Server should issueAccess Tokens that expire within an appropriate time. When an AccessToken expires, the Client requests a new Access Token from theAuthorization Server, which once again computes the Client'sauthorization, and issues a new Access Token... Two Profiles arerecommended for scenarios involving a Client acting autonomously:(1) Client Account and Password Profile, where the Client is provisionedwith an account name and corresponding password by the AuthorizationServer; (2) Assertion Profile, which enables a Client with a SAML orother assertion recognized by the Authorization Server...
More Info
Background: "As the internet has evolved, there is a growing trend fora variety of applications (Clients) to access resources through an APIover HTTP or other protocols. Often these resources require authorizationfor access and are Protected Resources. The systems that are trustedto make authorization decisions may be independent from the ProtectedResources for scale and security reasons. The OAuth Web ResourceAuthorization Profiles (OAuth WRAP) enable a Protected Resource todelegate the authorization to access a Protected Resource to one ormore trusted authorities.
Clients that wish to access a Protected Resource first obtainauthorization from a trusted authority (Authorization Server). Differentcredentials and profiles can be used to obtain this authorization, butonce authorized, the Client is provided an Access Token, and possiblea Refresh Token to obtain new Access Tokens. The Authorization Servertypically includes authorization information in the Access Token anddigitally signs the Access Token. Protected Resource can verify thatan Access Token received from a Client was issued by a trustedAuthorization Server and is valid. The Protected Resource can thenexamine the contents of the Access Token to determine the authorizationthat has been granted to the Client.
The Access Token is opaque to the Client, and can be any format agreedto between the Authorization Server and the Protected Resource enablingexisting systems to reuse suitable tokens, or use a standard tokenformat such as a Simple Web Token or JSON Web Token. Since the AccessToken provides the Client authorization to the Protected Resource forthe life of the Access Token, the Authorization Server should issueAccess Tokens that expire within an appropriate time. When an AccessToken expires, the Client requests a new Access Token from theAuthorization Server, which once again computes the Client'sauthorization, and issues a new Access Token... Two Profiles arerecommended for scenarios involving a Client acting autonomously:(1) Client Account and Password Profile, where the Client is provisionedwith an account name and corresponding password by the AuthorizationServer; (2) Assertion Profile, which enables a Client with a SAML orother assertion recognized by the Authorization Server...
More Info
Subscribe to:
Posts (Atom)