Showing posts with label OASIS. Show all posts
Showing posts with label OASIS. Show all posts

Thursday, July 01, 2010

Information Cards in JSON

I added some code to xmldap to serialize Information Cards to JSON.
The rationale is that XML and especially XML Signature are a mess on mobile devices. J2ME is java1.3 and thus from the stoneage. But Android (java 6) is not better because javax.xml.transform is missing. Arghh!

- I am throwing away namespaces
- No deaply nested XML structures.
- No signature (yet?)!

I would like to standardize this or something similar.

This is a Britisch Columbia Card from the RSA interop in JSON:


{
"CardId": "urn:GUID:6d6693c1-6b1a-df11-b009-00143851d232",
"IssuerName": "stsip.systestv2.bceid.ca",
"MimeType": "image/jpeg",
"lang": "en-us",
"TokenServiceList": [
{
"UserCredential": {
"Type": "UserNamePasswordAuthenticate",
"Username": "SBCEID\\pwiebe10i"
},
"Address": "https://stsip.systestv2.bceid.ca/adfs/services/trust/mex"
},
{
"UserCredential": {
"Type": "UserNamePasswordAuthenticate",
"Username": "SBCEID\\pwiebe10i"
},
"Address": "https://stsip.systestv2.bceid.ca/adfs/services/trust/mex"
}
],
"SupportedTokenTypeList": ["http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"],
"Issuer": "http://stsip.systestv2.bceid.ca/adfs/services/trust",
"CardVersion": 4,
"SupportedClaimTypeList": [
{
"Description": "Level of Assurance achieved according to the rules of the ICAM IMI 1.0 profile located at http://www.idmanagement.gov/",
"Uri": "http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assurancelevel1",
"DisplayTag": "ICAM Assurance Level 1"
},
{
"Uri": "http://www.cio.gov.bc.ca/standards/claims/2009/11/useridentifier",
"DisplayTag": "User Identifier"
},
{
"Uri": "http://www.ocio.gov.bc.ca/standards/claims/2009/06/userdisplayname",
"DisplayTag": "User Display Name"
},
{
"Uri": "http://www.ocio.gov.bc.ca/standards/claims/2009/09/identityassurancelevel",
"DisplayTag": "Identity Assurance Level"
},
{
"Uri": "http://www.ocio.gov.bc.ca/standards/claims/2009/09/authoritativepartyidentifier",
"DisplayTag": "AP Identifier"
},
{
"Uri": "http://www.ocio.gov.bc.ca/standards/claims/2009/09/authoritativepartyname",
"DisplayTag": "AP Name"
},
{
"Uri": "http://www.cio.gov.bc.ca/standards/claims/2009/09/identityassurancelevel1",
"DisplayTag": "Identity Assurance Level 1"
},
{
"Description": "The e-mail address of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
"DisplayTag": "E-Mail Address"
},
{
"Description": "The given name of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
"DisplayTag": "Given Name"
},
{
"Description": "The unique name of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"DisplayTag": "Name"
},
{
"Description": "The user principal name (UPN) of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
"DisplayTag": "UPN"
},
{
"Description": "The surname of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
"DisplayTag": "Surname"
},
{
"Description": "The private identifier of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier",
"DisplayTag": "PPID"
},
{
"Description": "The SAML name identifier of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
"DisplayTag": "Name ID"
},
{
"Description": "Used to display the time and date that the user was authenticated",
"Uri": "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant",
"DisplayTag": "Authentication time stamp"
},
{
"Description": "The method used to authenticate the user",
"Uri": "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod",
"DisplayTag": "Authentication method"
}
],
"CardName": "BCeID Information Card",
"TimeIssued": "2010-04-15T17:52:07.341Z",
"RequireAppliesTo": false,
"CardType": "urn:GUID:6d6693c1-6b1a-df11-b009-00143851d232",
"CardImage": "/9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABQAHgDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD340ZNBrg/FXxAGi301lbwGR4xhmCbhn9Py9qyrVoUo80jCviKdCPNUZr6l470TSbyO3u7pU3MFLZ+7k8Ej05/LtXS5NfJevXkuu+IYYVLLNczqiBjlRuIA+vNfV0TCOOOKSRTKFAPbJx6V6eNo0aMKc6cr8yv+VgoVXVTfQmzzS00dadXCbhRRRQAUUUUAFFFFABRRRQAUUUUAIa8M+KETWfiK6dJAY5grt3KsVHavUPGt5qNpoyf2asxkklCO0Kksq4PTHI7c15Le6ZqF4GMunXjseu6Fjn615ePqybVJU2+t+x4ebVZyaoxpuWzvY4a9037T5FyksiyqAYmVsFT1GD14Ne0atf3cNtAoupWEYWNsvlnKjBJPUnIJz6159ZeBL3U9UWNoZtPjQeYZ5YyNuCMbR3OSK7PUtGkWKNGv5ZCjeY5cAGRvUgdMnsK4uIs0hiaVCglyOG617K35M+m4YgneVSLW1rnqWmztc6ZaTuctJErMfUkc1brmvB+sRX1gLHyWims0VSC24MPUH+ldLXt4erGrSjOLumZ4ilKlVlCSsFFFFbGIUUUUAFFFFABRRRQAUUUUAIaMGlooAq3lhbX8apdRCRVOQCSMH8Konwvox62EZ/4E3+NTeIbuaw8NareW7BZ7ezlljYjOGVCQcH3Fckb3xJD4Eh8SQ6yJ5ltRdS29xbx+WwxkgFQCOPc0KipatIOdx2OxsNHsNMd3s7WOFnGGK55FXq5mbxlaWfgm38R3cbIs0SssCn5mdhwo/H9OaksbLXtStkutT1J7F5BuFpZon7oHszsCSfXGBTUOVdhOV2dFRXO2tvruneI4YpdQkv9JnifJliUPDIMEZZQMgjNblzdQ2kXmTyBF6c9z7UpNRV2xq7JqKy21RLiYWQFxazTITHIVXI9wDn9RXO+DtR1nVNc1uG/1RpYNNujBHGsMa+YPm5Yhc+nTFKnKNRNxewSTi0mdtRXBrea9cfEW60D+3JIrOO0F0rJbRb+SBtyVIxyea1NUj8T6Rave2F/HqixDc9rcwqjuo67WQAZ+orTk1tcnmOoorJ8N+ILTxNo0WpWmVVsq8bdY3HVTWtUtNOzKTuFFFFIAooooAxPGL+X4K1w4zmxmH5oR/WuQt/Dmr6x8OdNjttZYobSN/sckSiOUAZCFlw2O3Wu18S6dc6v4cv9OtHiSa5iMQaXO0A8Hp7ZrH0nSvFGm+HYNIE+lqYYvKW6BdmA6A7MAEj61rCVo/MiSuzgte8QLrnhPwvqL2q21raamsN1Cg+RCoGMe23P8q9pBBAIOQa5uy8EaVbeEW8OzK09vJlpZG4ZnPO/2PTH0pmlaf4k0G3SxSa01SziG2F53aGZV7AkBg2PXinNxkrLoKKa3OnZgqkngCuXtGutY1GW+SONo4iUh8xvlT3wOpqePTdZ1DWYrzVJbaG0gRxFaWzM5LsNu5mIGcAnAA707TtM1XTlkt4prfyWbIdgSw/CvMxcJOcFq49bdzqoySjJ9S/aaUIrs3lxKZ7kjAYjAUegFct4B/5GHxh/2Ej/AFrshHNBZlIWE0wBKmZiAze5AOB9BXMeFvD2taJrGq3V3JYSw6lcGdxE7hozzwMrz1HpXZQhGFNpaXMZtykmVLT/AJLVf/8AYJX/ANDWu5JAUk8Ada4dvDviaPxvJ4kgfS/ngFu1s0kmCnB+9t65HpWvf2Gv6zbNZz3Fpp1tKNsrWrNLKynqAzBQufXBraVnbUhXVznPhKh+x67PGCLSXUHMPoQPT9K9FqnpemWmjabDYWMQit4Vwqj+Z9SauVE5c0myoqysFFFFSMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD//Z"
}


Minor nit: lang="en-us". Might be better to use "en-ca"?

Thursday, April 15, 2010

SHA256 et al in openinfocard

I just added support for RSA-SHA256 etc to openinfocard's signature validation.
This came up during the RSA conference' OASIS IMI interop. The cards issued by ADFS2 are signed using RSA-SHA256. The team from the Government of British Columbia suggested to configure ADFS2 to use SHA1 for card signing but this way is better. Openinfocard is now more flexible in regard to signing algorithms. I added all DSA and RSA algorithms from http://www.w3.org/TR/2010/WD-xmlsec-algorithms-20100316/

Enjoy.

Thursday, March 18, 2010

Identitymanagement and Sex

I learned something this morning. There is an ISO norm (ISO-5218:2004) that defines the representation of human sexes in IT systems "Codes for the
representation of human sexes
". Probably there is an ISO norm for everything?

The actual representation looks similar to what is defined in the OASIS Identity Metasystem Interoperability standard.

0 - Not known
1 - Male
2 - Female
9 - Not applicable

IMI does not reference ISO-5218:2004 and "0 - Not known" is something different than "0 - unspecific". I guess the authors of the IMI spec do not know the ISO norm. Or is this due to the English differentiation of "sex" and "gender"? The ISO norm defines "sexes" and the IMI standard defines "Gender".
Interesting is the sheer number of "standards" to represent gender/sex.
http://de.wikipedia.org/wiki/Datenstandards_zur_Beschreibung_des_Geschlechts
(I have not found this in the English version of Wikipedia; Sorry.)
I find it interesting too that "transgender male" and "transgender female" do not exist in many standards. Although it may be inappropriate or even illegal to store the transgender information in a database but this is not the issue. Somebody might want to prove that he was formerly a she. It is better to have a representation in a norm/standard for all cases. The legal issues are outside the standard. ("legal" is always a path to headache for me e.g. http://de.wikipedia.org/wiki/Transsexuellengesetz)
OASIS should always check that new OASIS standards might be aligned to older existing standards.
I think the "gender" section of the IMI standard should be revised.

Thursday, February 26, 2009

Public Review of Identity Metasystem Interoperability Version 1.0

OASIS has sent the following information out today:

The OASIS Identity Metasystem Interoperability TC has recently approved the following specification as a Committee Draft and approved the package for public review:

Identity Metasystem Interoperability Version 1.0

Introduction:
The Identity Metasystem Interoperability specification prescribes a subset of the mechanisms defined in WS-Trust 1.2, WS-Trust 1.3, WS-SecurityPolicy 1.1, WS-SecurityPolicy 1.2, and WS-MetadataExchange to facilitate the integration of Digital Identity into an interoperable token issuance and consumption framework using the Information Card Model. It documents the Web interfaces utilized by browsers and Web applications that utilize the Information Card Model. Finally, it extends WS-Addressing's endpoint reference by providing identity information about the endpoint that can be verified through a variety of security means, such as https or the wealth of WS-Security specifications.

This profile constrains the schema elements/extensions used by the Information Card Model, and behaviors for conforming Relying Parties, Identity Providers, and Identity Selectors.

The public review starts today, 26 February 2009, and ends 27 April 2009. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work. Please feel free to distribute this announcement within your organization and to other appropriate mail lists.

More non-normative information about the specification and the technical committee may be found at the public home page of the TC at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=imi. Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button marked "Send A Comment" at the top of that page, or directly at http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=imi.

Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at http://lists.oasis-open.org/archives/imi-comment/. All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the
feedback you provide carries the same obligations at least as the obligations of the TC members.

The specification document and related files are available here:

Editable Source:
http://docs.oasis-open.org/imi/identity/v1.0/cd/identity-1.0-spec-cd-02.doc

PDF:
http://docs.oasis-open.org/imi/identity/v1.0/cd/identity-1.0-spec-cd-02.pdf

HTML:
http://docs.oasis-open.org/imi/identity/v1.0/cd/identity-1.0-spec-cd-02.html


Schema:
http://docs.oasis-open.org/imi/identity/v1.0/cd/identity-1.0-cd-02.xsd
http://docs.oasis-open.org/imi/identity/v1.0/cd/addr-identity-1.0-cd-02.xsd
http://docs.oasis-open.org/imi/identity/v1.0/cd/claims-1.0-cd-02.xsd

OASIS and the IMI TC welcome your comments.


I hope that we will have an official OASIS standard for Information Cards soon.
Well, musing about "soon". I am wondering how long these things take. I joined Chuck Mortimore and the Openinfocard project in August 2006. We had the first open source Information Card relying party and the first open source IdP, both written in Java and Java Server Pages. Then of course the first open source card selector as an Firefox extension, written in javascript, XUL and Java.
Time is flying when you are having fun.

Wednesday, June 11, 2008

OASIS event

September 30-October 3, 2008

Topics include, but are not limited to:

  • High-level overviews of security challenges, and the landscape of security standards being developed to address them
  • Case studies, requirements, deployment overviews, profiles from specific sectors or application areas (e-governments, telecom, financial services, healthcare...)
  • Authentication of citizens in cross-border government services, issues related to mutual recognition of authentication services
  • Information cards and information card interoperability
  • Federated technologies
  • Access control, access control models, policies, and privacy issues
  • Key management (PKI or symmetric key-based)
  • Digital Signatures, electronic signatures, server-based signature processing, technical and legal issues.
  • Securing Web Services: WS-I profiles; recent Web Services security specifications


This happens together with the workshop "Adopting SOA for Telecom".
Sounds interesting, I would like to attend. Gerry Gebel is giving the keynote and Anthony Nadalin is on the workshop committee.