January 28, 2012

Guide to Running a User Account System (Google)

Introduction: User Account Systems
The hack that makes Internet Identity possible
Which face are you presenting to the world?
Human -> Emails -> Local IDs -> Passwords
The Weakest link
So what happened in 2008?
Secure mashups
Chapter 1: Account Chooser
Requirements
The Account Chooser Experience
Central Account Chooser
Local Account Chooser
Local + Central
Email providers and Account Choosers
Passwords and Account Choosers
Chapter 2: Mobile/Desktop Apps
Chapter 3: What is an Identity Provider?
Chapter 4: Baby steps to passwordless login
Chapter 5: Identity Providers and Email Providers
Account Chooser without passwords
The Email Attribute
Full Rollout
Login with a button
Session Lifetime
Persistent or Session Cookies
Cookie lifetime
Single Sign Out
Chapter 6: Popular Identity Providers and Social Login
The good, the bad, and the ugly
Account Chooser and Popular Identity Providers
Login with a button
Account Linking Wizard
Chosen account has no IDP
IDPs that do not assert Email address
Per-RP IDs
Chapter 7: Consuming APIs
Chapter 8: Local Social Graph
Chapter 9: Certification of Providers
Chapter 10: Exposing APIs
Chapter 11: Relationship Managers
What are the advantages?
Examples
Chapter 12: Relationship Guides
Chapter 13: Identity Verification and Attribute Providers
Chapter 14: Stronger authentication for users
Phishing protection
Mixed Strong Authentication
Economics of consumer strong authentication
Chapter 15: Stronger authentication for robots
Robots and Dynamic Registration
Chapter 16: Conclusion

via docs.google.com

Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »

1:40am | URL: http://hdknr.com/post/16582395287/guide-to-running-a-user-account-system-google

FILED UNDER: DigitalIdentity Google

January 20, 2012

Connect Client Credentials Flow with JWT Assertion : #512 - Standard : 2.2 : “two main paths” means other flow can be used , or not ? — Bitbucket

John Bradley / ve7jtb
written 2 hours ago

Yes the idea is that other flows like “JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0” can be used.

A extension document probably needs to be written for each additional flow.

via bitbucket.org

Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »

10:43am | URL: http://hdknr.com/post/16147044443/connect-client-credentials-flow-with-jwt-assertion

(No. OF NOTES: 1)

FILED UNDER: Assertion Connect Credential JWT

Assertion Flow in Connect ? ( Draft: OpenID Connect Standard 1.0 - draft 07 )

Authorization Requests follow two main paths to obtain Access Tokens and ID Tokens, the Implicit Flow and the Authorization Code Flow.

via openid.bitbucket.org

Looks no. Draft should be slightly changed ?

Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »

1:35am | URL: http://hdknr.com/post/16119126285/assertion-flow-in-connect-draft-openid-connect

(No. OF NOTES: 1)

FILED UNDER: Authorization Connect Grant OpenID

January 17, 2012

Mike Jones: self-issued » SWD, JWT, JWS, JWE, JWK, and OAuth JWT Profile specs updated

This checkin is intended to be the last set of individual submissions of the JWS, JWE, and JWK drafts before they are refactored and submitted to the JOSE WG as working group drafts. The primary changes requested by the JOSE WG but not yet done are to break the algorithm profiles and identifiers out into a new spec and to rework the terminology in the signature spec to use different terms for digital signature and HMAC integrity operations.

See the Document History sections of each document for a detailed description of the changes made. These documents are available at:

http://tools.ietf.org/html/draft-jones-simple-web-discovery-02

http://tools.ietf.org/html/draft-jones-json-web-token-07

http://tools.ietf.org/html/draft-jones-json-web-signature-04

http://tools.ietf.org/html/draft-jones-json-web-encryption-02

http://tools.ietf.org/html/draft-jones-json-web-key-03

http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03

HTML-formatted versions are available at:

http://self-issued.info/docs/draft-jones-simple-web-discovery-02.html

http://self-issued.info/docs/draft-jones-json-web-token-07.html

http://self-issued.info/docs/draft-jones-json-web-signature-04.html

http://self-issued.info/docs/draft-jones-json-web-encryption-02.html

http://self-issued.info/docs/draft-jones-json-web-key-03.html

http://self-issued.info/docs/draft-jones-oauth-jwt-bearer-03.html

via self-issued.info

Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »

10:21am | URL: http://hdknr.com/post/15981663437/mike-jones-self-issued-swd-jwt-jws-jwe-jwk-and

FILED UNDER: JOSE JWE JWS JWT

JOSE: [woes] Proposed charter, post-Quebec edition

From Evernote:

JOSE: [woes] Proposed charter, post-Quebec edition

Clipped from: http://www.ietf.org/mail-archive/web/woes/current/msg00160.html#

Here is a proposal for the charter based on the discussion in the BoF last week and later discussion with Sean Turner. Comments, praise, scorn, etc., are welcome. --Paul and Richard Javascript Object Signing and Encrypting (jose) =============================================== Background ---------- Javascript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used for serializing and transmitting structured data over a network connection. With the increased usage of JSON in protocols in the IETF and elsewhere, there is now a desire to offer security services such as encryption and digital signatures for data that is being carried in JSON format. Different proposals for providing such security services have already been defined and implemented. This Working Group's task is to standardize two security services, encrypting and digitally signing, in order to increase interoperability of security features between protocols that use JSON. The Working Group will base its work on well-known message security primitives (e.g., CMS), and will solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is correct. This group is chartered to work on four documents: 1) A Standards Track document specifying how to apply a JSON-structured digital signature to data, including (but not limited to) JSON data structures. "Digital signature" is defined as a hash operation followed by a signature operation using asymmetric keys. 2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures. 3) A Standards Track document specifying how to encode public keys as JSON-structured objects. 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents. The working group may decide to address one or more of these goals in a single document, in which case the concrete milestones for signing/encryption below will both be satisfied by the single document. Goals and Milestones -------------------- Aug 2011 Submit JSON object signing document as a WG item. Aug 2011 Submit JSON object encryption document as a WG item. Aug 2011 Submit JSON key format document as a WG item. Aug 2011 Submit JSON algoritm document as a WG item. Jan 2012 Start Working Group Last Call on JSON object signing document. Jan 2012 Start Working Group Last Call on JSON object encryption document. Jan 2012 Start Working Group Last Call on JSON key format document. Jan 2012 Start Working Group Last Call on JSON algorithm document. Feb 2012 Submit JSON object signing document to IESG for consideration as Standards Track document. Feb 2012 Submit JSON object encryption document to IESG for consideration as Standards Track document. Feb 2012 Submit JSON key format document to IESG for consideration as Standards Track document. Feb 2012 Submit JSON algorithm document to IESG for consideration as Standards Track document.

Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »

10:12am | URL: http://hdknr.com/post/15981122603/jose-woes-proposed-charter-post-quebec-edition

FILED UNDER: JOSE JWS JWT

December 22, 2011

Ad Hoc OAuth server

From Evernote:

Ad Hoc OAuth server

A RP can be a OAuth server for the other RP(client).

With providing kinda “License Token” to a RP, the RP can be securely provide End-User’s protected resource to the other RP.

(1) OAuth ”code” is delivered to a Client RP

(2) Request an access token.

(3) Issue an access token if the Client RP, code and other conditions are valid.

(1)-(3) are can be omitted if OAuth flow is implicit.

OP embeds “license code” as a claim of the access token, which is a kinda access code for the Server RP in a particular authorization.

A specific Server RP is selected when the End-User grants the authorization.

(4) The Client RP request the resource for the access token. That’s an OAuth.

(5) The Server RP request the “license token” for the license code in the access token requested by the Client RP.

(6) Issue the license token for the access token if the license code, the Server RP and other conditions are valid.

In license code, PPID for the Server RP of the End-User and other claims are included to response the End-User’s protected resource.

(7) Load resource for the license token if the relationship with access token and other conditions are valid.

(8) Publish protected resource to the Client RP.

Point:

- The Client RP is just a OAuth client. It doesn’t know what special are going on underneath.

- The Server RP doesn’t have to implement OAuth Authorization Server process.

- PPID can be used. Client and Server don’t have to share the End-User’s identifier.

- Licence Code and Token can be easily implemented at the Authorization Server(OP) in mostly same way as access token.

Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »

10:03am | URL: http://hdknr.com/post/14590763402/ad-hoc-oauth-server

(No. OF NOTES: 1)

FILED UNDER: Connect OAuth

Ad Hoc OAuth server

From Evernote:

Ad Hoc OAuth server

A RP can be a OAuth server for the other RP(client).

With providing kinda “License Token” to a RP, the RP can be securely provide End-User’s protected resource to the other RP.

(1) OAuth ”code” is delivered to a Client RP

(2) Request an access token.

(3) Issue an access token if the Client RP, code and other conditions are valid.

(1)-(3) are can be omitted if OAuth flow is implicit.

OP embeds “license code” as a claim of the access token, which is a kinda access code for the Server RP in a particular authorization.

A specific Server RP is selected when the End-User grants the authorization.

(4) The Client RP request the resource for the access token. That’s an OAuth.

(5) The Server RP request the “license token” for the license code in the access token requested by the Client RP.

(6) Issue the license token for the access token if the license code, the Server RP and other conditions are valid.

In license code, PPID for the Server RP of the End-User and other claims are included to response the End-User’s protected resource.

(7) Load resource for the license token if the relationship with access token and other conditions are valid.

(8) Publish protected resource to the Client RP.

Point:

- The Client RP is just a OAuth client. It doesn’t know what special are going on underneath.

- The Server RP doesn’t have to implement OAuth authorization process.

- PPID can be used. Client and Server don’t have to share the End-User’s identifier.

- Licence Code and Token can be easily implemented at the Authorization Server(OP) in mostly same way as access token.

Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »

10:02am | URL: http://hdknr.com/post/14590744692/ad-hoc-oauth-server

FILED UNDER: Connect OAuth

December 16, 2011

Connect/OAuth: Credentials

Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »

10:52am | URL: http://hdknr.com/post/14288901395/connect-oauth-credentials

December 4, 2011

JSON Web Signature (JWS)

Holder-of-Key JWS ¶

by HDKNR

For higher LoA, OpenID Connect with JWS may support holder-of-key tokens, and Connect request may support TLS with client certificates. Mimicking some great SAML works is easy to do those : SAML V2.0 Holder-of-Key Assertion Profile Version 1.0 and SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 .
JWS ¶

JWS is easily extended to include a holder-of-key info, i,e, X.509 Data in SAML HoK. I’m not sure if we have to provide multiple X.509 Data in a single JWS token now. JWS Header may have “sbj”, which means “subject confirmation” and is equal to <saml:SubjectConfirmationData> in SAML HoK.

“sbj” claims contains JSON object in which describes a certificate for the “atesting entity”. “atesting entity” can be an End-User if the JWS token is an Identity Token(id_token) of Connect, also a Relying Party if the JWS token is Access Token(access_token) of OAuth.

JWS with “sbj” looks like this:
{ "alg": "RS256", "typ": "access_token", "x5u": "public key url for issuing party(authz server)", "sbj": { "x5c": "copy of OAuth client's certificate" } }
“sbj” must one of 4 claims if we follow the SAML HoK:

“x5c”

Base64url encoding copy of atesting entity’s X.509 certificate.

“x5i”

Copy of “Subject Key Identitier” in atesting entity’s X.509 certificate.

“x5s”

Serial number isseud by a Certificate Authority in atesting entity’s X.509 certificate.

“x5n”

Copy of “DN(Distinguished Name)” in atesting entity’s X.509 certificate.

“x5c” is best for server entities to validate holder-of-key, but too big for a JWS token. “x5i” > “x5s” > “x5n” may be the best order in rest. But “x5i” is only for certificates which inlcude extended parameter. So “x5s” may be MUST if entities in a OAuth/Connect circle support holder-of-key.
Endpoints ¶

OAuth and Connect endpoints SHOULD accept TLS with client certifaictes if they supoort holder-of-key validation. Such endpoints may be Authorization endpoints, Token endpoints,Resource endpoints and Request Registraton endpoinst of Connect. Endpoints may simplly follow the SAML HoK tao.

Implict Flow ¶

If the case is without a Request Registration of Connect, there is no chance for an issuer(Authz Server) to check the Relying Party’s client certificate for the Implicit Flow. If an issuer thinks of the registered certificate as the valid X.509 certificate, it may work.

If a case is for javascript access to resource with HoK-ed JWS access token, JWS ‘sbj‘ is for End-User(‘s User Agent). That needs some tricky selection flow at Authorization Endpoint.