PATCH メソッド、新しい HTTP Status Code - 日向夏特殊応援部隊
Spec はあまりミーハーに追いかけても後で痛い目にあったりするもんですが、久しぶりに面白いなーと思ったのでちょっと取り上げてみます。 ちなみに斜め読みなので記事の正確性についてはあまり保証しませんw PATCH Method for HTTP RFC 5789 にある PATCH Method for HTTP ですが、RESTful API の致命的な弱点でもある PUT がリソースの完全なる置き換えなのに対して、PATCH は差分適用である所が中々面白いです。 2.1. A Simple PATCH Example のサンプルを見てみます。 PATCH /file.txt HTTP/1.1 Host: www.example.com Content-Type: application/example If-Match: "e0023aa4e" Content-Length: 100
続・モバイル用の OpenID 考 - 日向夏特殊応援部隊
ちょうど今日、有志でモバイル用 OpenID について議論してきたので気分転換に。 モバイル用の OpenID 考 - Yet Another Hackadelic OpenID for mobile と言う題目で idcon #4 で話してきました - Yet Another Hackadelic の続きです。 ニーズの話 OP 側の視点がメインです。但し一方的に OP だけにシナジーがあっても使われる訳が無いので RP にもメリットがあるといいねという感じで考察してみます。 SSO システムとしての OpenID 前はニーズについては触れなかった。認証の簡略化という意味で端末IDは現実的に使われていて、仮に異なるサービス間だとしてもその端末IDさえ何らかの形で共有出来れば同一IDでのSSOは実現出来る。 それが自社内の異なるコンテンツならばまったく問題は無いけど、異なる会社の異なるサー
Re:OpenIDが面白いのはWebサービス間の連携 - 日向夏特殊応援部隊
概ね核心をついているんだけど、少し分かりにくいと思ったので補足してみたりとか。 元ネタ F's Garage @fshin2000 ：OpenIDが面白いのはWebサービス間の連携 結局、それなりに責任が伴うサービスとしては二段構えの対応にならざるを得なく、「お試し利用としてのOpenID対応」というフェーズと、「本気で使うならうちに個人情報を登録してね」という状態は分かれるだろう。 ユーザーサポートが絡むサービスであればあるほど、この部分は意識せざるを得ないし、マーケティングという大人の事情も絡めば絶対に無視できない。ネットのサービスはHTTPだけで完結するものではない。 f-shinさんが言っている「お試し利用」と「本気の利用」ってのは恐らく、メールアドレス等の個人情報を自前で持つか持たないかの話だと思うんですが合ってますかね？ Simple Registration Extensio
第1回アイデンティティ飲み会 - Yet Another Hackadelic
期待もこめて第1回と銘打っておきます。（ぉ あと、まだほろ酔いなので内容についてはスルーの方向で。 最終的に参加者は、 http://blogs.sun.com/tkudo/entry/identity_nomi_next_friday となった訳*1ですが、とても考えさせられる飲み会でした。 OpenIDだとかSAMLだとかの切り口の違いって、 誰をターゲットにしてるのか ビジネス的にどーよ って話で分けられるのかなとか思いました。 実はOpenID云々の話は僕は余りしていなくて、SAMLの話の方がにぎやかだった気がするんですが、SAMLが何者でOpenIDと対比してどうなのかは余りオンラインで話題になってない気がするんですけど。どうなんだろう。 id:shinichitomitaがSAMLについての入門を書いてくれるらしいのですが、それに期待すると言う事で。 個人的にはnat=さんのR
Yet Another Hackadelic - OpenID Providerのreputation問題、AOLの方針など
久しぶりに真面目にエントリを書いて見ます。OpenIDのreputation問題に関して、AOLがちょっと前に打ち出した一つの方針について思うところを書いてみます。 reputationとは OpenIDに関するreputation問題とは、Claimed Identifierが指し示すIdP/OP*1が信頼するに値するかどうかと言う評価・評判の事です。 と言うのもIdP/OPと言うのは誰でもでっち上げる事が出来るので、どこの馬の骨とも分からないIdP/OPでも何も対策しなければ許可してしまうのがOpenIDの仕様です。 そのIdPを提供するwebサイトに脆弱性があり、アカウントがクラックされでもしたら、そのようなアカウントをもって認証されたユーザーを信頼できるでしょうか。 よって何らかの指針を持ってして、OpenIDのIdP/OPを評価しなければならないのでは無いか…と言うお話です。 A
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
