OAuth.jp

The AS->RS work is probably simpler and more useful at this point.

—

Re: [OAUTH-WG] OAuth WG Re-Chartering

リソースサーバーと認可サーバーとの間のトークン検証のやりとりの仕様策定が、今後の OAuth WG のお題に入りそうな感じ

(via tkudo)

response_type=code tokenとかあるので仕様曖昧だよな～と思っていたのですが、普通に書いてありました。

A client application consisting of multiple components, each with its own client type (e.g. a distributed client with both a confidential server-based component and a public browser-based component), MUST register each component separately as a different client to ensure proper handling by the authorization server.

Clientはユーザーに代わって保護リソースにアクセスするアプリケーション。 Client Typesとして、秘密鍵を安全に管理できるconfidential、クライアントサイドで動いて管理できないのはpublic。 ConfidentialならAuthZ Code, PublicなのはImplicit使え。 サーバーサイドとクライアントサイドの両方のComponentから構成されている場合、別々で登録しろ！

—

OAuth 2.0でユーザーが認可をする”アプリケーション”とはサービス全体のことではない – r-weblife

で、そういう状況でどうやって効率的に同意を取るかは、AuthZ Serverの実装依存、か。。。

(via kyomichi)

JSO - a Javascript OAuth Library

—andreassolberg/jso

研究の第一弾では学生IDを民間サービスで安全に利用するための「Student Identity Trust Framework」を策定。2012年中に、民間企業がフレームワークに準拠した学生向けサービスを提供できるよう支援する。

これにより、学生は大学が発行するIDで民間企業のサービスにログインして、学割などの特典サービスをオンラインで受けられるようになるほか、企業側は自社でID管理や資格確認などの仕組みを構築しなくても、大学が提供する「その人が学生である」という情報を基に学生へ自社サービスを提供できる。

—

産学でのID連携を実現する「トラストフレームワーク」、NIIとOpenIDが共同研究へ – ITmedia エンタープライズ

記事タイトルはご愛嬌。