About
Accounts
Friends
-
Loading…curara 2 days ago -
Loading…Tokyo 8 months ago -
Loading…shigekicks 7 days ago
Click here to check if anything new just came in.
January 27 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 Account Chooser Experience
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
Chapter 6: Popular Identity Providers and Social Login
The good, the bad, and the ugly
Account Chooser and Popular Identity Providers
IDPs that do not assert Email address
Chapter 9: Certification of Providers
Chapter 11: Relationship Managers
Chapter 12: Relationship Guides
Chapter 13: Identity Verification and Attribute Providers
Chapter 14: Stronger authentication for users
Economics of consumer strong authentication
Chapter 15: Stronger authentication for robots
Robots and Dynamic Registration
Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »
January 22 2012
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
January 19 2012
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.
Looks no. Draft should be slightly changed ?
Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »
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
Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »
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 »
January 15 2012
January 14 2012
New Year Wishes
初詣は青山熊野神社でおまいりしたのですが、機会があったので等々力不動尊でもおまいりしました。ことしも東急にはお世話になるので。無事事故の無い一年を送れたらいいですね。
市川で元旦を過ごして翌日はNeのおばさんの家に遊びに行きました。以前から遊びに来てね、といわれていたのになかなか顔を出す事ができなかったのか心に残っていたので良い機会だったので。
これまでRiさんは他のおばさんと区別できなかったようですが、楽しく優しくしてもらってとても楽しかったようで、次回はちゃんと名前言えると思います。
成人の日の三連休も過ぎてようやく新年本番な感じです。ミュージカルの春の発表のディズニーの英語の歌もだいぶ覚えたようで良いスタートを切れたのかな。
January 08 2012
January 01 2012
December 30 2011
今年もありがとうございました。
年の最後に通学路の掃除をしました。
Riさんは掃除が大好きで、夕方Miが帰宅すると掃除を手伝わされたりします。
前からどうしても道端の枯れ葉掃除をしたかったらしく、東急ハンズで清掃道具を買ってきました。
先週に引き続き、今週も掃除。年末なので、たばこの吸い殻を沢山やっつけました。
来年もいい年になりますように。
December 25 2011
December 22 2011
Ad Hoc OAuth server
From Evernote:
Ad Hoc OAuth server
Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »
Ad Hoc OAuth server
From Evernote:
Ad Hoc OAuth server
Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »
December 18 2011
December 16 2011
Connect/OAuth: Credentials
December 11 2011
December 04 2011
December 03 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.
Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »
December 02 2011
OAuth HoK : (2) token endpoint
(1) implicit flow can’t be used.
(2) refresh tokens can be HoK-ed.
Posted via email from Notes for Digital Identities and Computing in the Cloud | Comment »
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
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.