Archive for the ‘Uncategorized’ Category
So this is getting very interesting: The world’s largest chip maker wants to see a new kind of economy bloom around personal data (article here).
It looks like Intel is entering into the personal data & big data narrative. Given that Intel owns a considerable chunk of the motherboard & SoC real-estate (think Processors, discrete TPMs, AMT, etc. etc), they do indeed have access to the plumbing of my machine.
One question is whether hardware and chipset providers will begin to require end-users to agree to Terms of Service (allowing them to access data bits moving around the board). Such a move would complicate the user’s life. A typical person would then be forced to accept TOS and EULAs at three layers (at least):
- The hardware layer.
- The OS level (think EULAs)
- The application layer (think EULAs when installing Office productivity tools)
- The Services Provider (SP) and IdP layer (think Click-Thru agreement when signing-up to accounts)
MIT Media Lab – 2013 Legal Hack-a-thon on Identity
Today we had the privilege of hearing a presentation by Loius Wingers and Stefan Treatman-Clark on a couple of lightweight ciphers from the NSA. These are called SIMON and SPECK. The algorithms are not yet published, but they have a paper (pdf copy here) that shows some numbers on the performance of the proposed ciphers.
The SIMON and SPECK algorithms come in a family that range from 48-bits to 128-bits. Since the target deployment area is low-power and low memory devices (i.e. RFID devices, etc), the requirement is that these algorithms do not use more than 2000 gates. The paper has a table showing the GE and throughput.
Louis and Stefan presented SIMON and SPECK at the 2013 Legal Hack-a-Thon and the MIT Media Lab.
After over 6 weeks of the IDESG Governance subgroup drafting the IDESG Membership and ROA related docs, these are finally completed.
(1) Proposed Membership Agreement
(2) Proposed Intellectual Property Rights Policy
(3) IDESG Rules of Association
Key Dates and Times
- Ballot on the Membership Agreement & IPR Policy opened at 12:00 noon ET on December 3, 2012
- Ballot on the Membership Agreement & IPR Policy will close at 12:00 noon ET on December 17, 2012
Since I’m editing the User Managed Access (UMA) Core spec, I always seem to be getting questions about UMA. Also I’ve noticed that some folks in the IETF OAuth2.0 WG have not really understood the UMA flows (not suprising, since the UMA Core Rev 5C is now over 40 pages long). So I thought a very high level tutorial would benefit lots of people.
So here goes Part 1 of the tutorial.
When a Requester (acting on behalf of a Requesting Party) seeks access to resources sitting at the Host, the Requester must obtain an OAuth2.0 token from the Authorization Manager (AM). In this case the Requester is behaving like an OAuth Client, while the AM is behaving like an OAuth2.0 Authorization Server (AS). The resulting token is referred to in the UMA specs as the Authorization API Token (AAT). This token allows the Requester to use the other APIs at the AM at a later stage. It signals authorization by the AM for the Requester to access the other APIs at the AM.
After the Requester gets its own AAT token, it must now get another token specific to the Requesting Party (call him Bob). This token is referred to as the Requester Permission Token (RPT). Later when Bob (the Requesting Party) is seeking to access resources to at the Host (e.g. MyCalendarsz.com) by employing the Requester (e.g. TripItz.com), the requester must forward both tokens (the AAT and the RPT tokens) to the Host.
The reason why two tokens are needed is that there might be multiple Requesting Parties (eg. Bob, Billy, Becky, etc) at the same Requester (TripItz.com) seeking to access the same resources at the same Host. However, the Requester needs to be authorized only once by the AM to access the AM’s APIs.
[In the next post, we'll see how the Host has to do the same basic registration to the AM]
For SAML2.0 developers, users and vendors, it is perhaps worthwhile noting that the OASIS Security Services TC (SSTC) has started the process of revising the SAML2.0 specs.
Here is what the SSTC group has agreed to so far:
- All approved errata, along with any errata presented to the TC subsequent to the last approval, are to be applied to the specifications, or the specifications may be reworded to include the spirit of the errata identified.
- All original SAML 2.0 message formats are intended to remain unchanged in the new version except in cases where outright errors existed and were corrected through errata or subsequent specifications. This includes preservation of core XML namespaces.
- To the greatest extent possible, existing implementations of SAML 2.0 features should be compatible with the new standard, and any areas of divergence should be minimized and clearly identified.
- Some extensions and profiles published after SAML 2.0 ought to be incorporated in some fashion into the base standard to promote adoption and reduce the number of documents needed to address critical features.
- Significant changes to the Conformance statements for the standard are to be expected. We do not expect that every new feature or existing extension would be made mandatory to implement.
- Material related to a variety of threats implementers ought to be aware of should be drafted and incorporated.
Please visit the wiki containing the SAML2Revision plans. The SSTC is seeking input from the broader SAML2.0 community.