Relying Party Best Practices (ko)
|
English | 日本語 | 中文(中国大陆) | 한국어 | +/- |
이 페이지는 적용서비스들(Replying Parties)에게 권장되는 몇가지 Best Practice 들을 소개합니다. 언젠가는 적용서비스들의 (구현상) 완성도를 평가하기 위한 좋은 리뷰 문서가 될 수도 있겠습니다. 일단은, 계속 작업중입니다.
유사한 맥락으로 이 목록을 개선해 주십시오. 각각의 항목들은 적절한 메일링 리스트나 위키 토론 페이지를 통해서 다루실 수도 있겠습니다.
이 문서는 대략 몇가지 "호환성 수준"(compliance levels)에 따라 나누어 집니다. 대부분의 적용서비스들은 최소한 첫번째 수준에 따라야 하며, 가능한 많이 호환되어야 합니다. (주) 각 수준의 더 좋은 이름을 지어야 할 것 같습니다.
대다수 이러한 요구사항들은 사용자가 로그인할 때 어떤 의미에서건 "계정"이라는 것을 제공하는 사이트들을 위한 것입니다. 만약 당신의 사이트가 단지 일회성 인증만 사용하고 특정 ID 에 대해서 아무런 지속적인 정보를 유지하지 않는다면, 이러한 요구사항들은 지나치셔도 됩니다.
Contents |
기초 수준 (Basic)
사이트는 사용자에게 OpenID ID 로 인증할 수 있게 합니다.
이것은 지극히 명백합니다. 이것을 지원하지 않는다면, 당신은 OpenID RP 가 아닙니다!
사이트는 인증된 사용자를 명확하게 구분 표시합니다.
어떤 사이트들은 인증된 사용자와 아닌 사용자를 모두 허용합니다. 만약 인증되지 않은 사용자들이 URL 을 자신의 속성중 일부로 표기하게 허용하는 경우, 반드시 URL 의 인증여부(예를 들면 OpenID) 를 명확히 구분해서 표시해야 합니다.
이유: 만약 이 두가지가 구분이 안된다면, 악의적인 익명사용자가 인증된 OpenID 사용자의 명의 도용이 가능해 집니다.
확장 기능은 필수가 아니라 옵션으로 처리한다.
만약 당신의 사이트가 인증과정중 어떤 확장 기능을 사용한다면, 이를 테면 간이등록확장(Simple Registration Extension), 인증 제공자가 그 확장 기능을 지원하지 않을 경우라도 무리없이 처리할 수 있어야 합니다. 간이 등록 확장의 예를 들면, 사용자에게 필요한 정보를 인증과정 완료후에 따로 기입하게 한다던지 또는 적절한 기본값을 사용하는 식입니다.
이유: 모든 제공자들이 모든 확장 기능을 지원하지는 않을 것이며, 확장과 관계된 오류 메시지들은 일관성없고 바람직하지 못한 사용자 경험을 만들기 때문입니다.
사용자의 OpenID 가 공개여부를 명확히 알린다.
어떤 사용자의 OpenID 를 공개하는 것은 제3 사이트들이 여러사이트 계정들을 연관지을 수 있게 하는 것이다. 사용자는 이를 인식해야 하며, 사용자 동의를 적절히 구하거나 아니면 게시되지 않도록 할 수 있어야 한다.
좋은 수준 (Would Be Nice)
OpenID 인증된 사용자들에게 모든 기능을 제공합니다.
많은 사이트들이 OpenID 인증과 전통적인 아이디/비밀번호 를 모두 받습니다. 이 두가지 인증 방식을 명확하게 구분하되, 양쪽 모두 같은 기능을 제공합니다.
주: 사실 OpenID 사용자들이 약관에 동의하고, 그림퀴즈를 맞추는 등 사이트에 처음 방문할 때 요구되는 일들을 수행하지 않을 이유는 없습니다. 따라서 OpenID 사용자들도 그 서비스 사용자들 만큼 신뢰할 만하게 될 수 있습니다.
이유: OpenID 사용자들을 '2류'로 취급하는 사이트에서는, OpenID 를 사용하고 싶지 않을 것입니다.
사용자들에게 기존의 아이디/비밀번호 방식으로 부터 OpenID 계정으로 "개선" 할 수 있게 합니다.
많은 사이트들이 기존의 전통적인 아이디/비밀번호 인증을 가지고 있습니다. 기존 사용자들이 OpenID 로 완전히 전환토록 하거나 자신의 계정에 비밀번호와 OpenID 아이디를 모두 연결해서 쓸수 있게 하십시오.
이유: 사용자들은 OpenID 를 사용하기 위해 그들의 예전 계정을 버릴 필요가 없어야 합니다.
사용자들이 그들의 계정과 연관된 OpenID 아이디를 변경할 수 있게 합니다.
로그인한 사용자가 두번째 OpenID 아이디로 인증을 하고, 기존의 OpenID 대신 새로운 아이디로 연결을 교체할 수 있게 하십시오.
이유: 사용자들이 그들의 계정(데이타등등)을 잃지 않고도 자신의 아이디를 변경할 수 있게 하십시오.
훌륭한 수준
"아이디 분실 회복" 기능을 제공하여 기존 아이디로 인증받지 않아도 새로운 아이디로 전환하게 하십시오.
계정과 연관된 예전 아이디를 분실한 경우, 새로운 아이디로 전환할 수 있는 방법을 제공하십시오. 이것은 사용자의 이메일만 저장하고 있다면 전통적인 "비밀번호 분실 회복 메일"같은 형태가 될 수 있습니다.
이유: 사용자들은 종종 아이디를 분실합니다, 제공자들이 서비스를 중단하는 경우도 있습니다. 이 기능은 사용자들에게 이런 상황에서도 그들의 데이타를 잃지 않고 회복할 수 있게 합니다.
계정들을 '통합'할 수 있게 합니다.
별개의 두 계정을 하나로 합칠 수 있게 하십시오, 방법은 서비스의 정해진 규칙을 통하거나 아니면 그냥 둘중 하나를 버리는 수도 있겠습니다.
이것은 특히 여러 아이디(OpenID 기반이든 구식의 아이디/비밀번호 방식이든) 와 하나의 계정의 연결을 허용하는 사이트들에 유용합니다.
이유: 사용자들은 별도의 OpenID 아이디를 가지고 로그인 하다가, 나중에야 그 사이트가 구식 계정을 전환시켜 주거나, 여러개의 아이디를 하나의 계정과 연결시켜준다는 사실을 알게 될 수 있습니다. 여러 아이디를 한 계정으로 통합시킴으로써 이러한 상황에 대처할 수 있게합니다.
하나의 "사용자 계정" 에 여러 identity URL 지원
처음 OpenID 로그인시 어떤 형태로든 사용자 계정을 생성하는 경우, 이 사용자 계정에 다른 OpenID URL 들을 추가하되 같은 사용자로 인식하는 기능을 제공합니다.
이유: 사용자들이 한 아이디에서 다른 아이디로 쉽게 바꿀 수 있는 기능을 제공하는 것이며, 나아가 여러 아이디들이 같은 사용자임을 보일 수 있게 합니다.
사용자들에게 유일한 사용자이름 요구하지 않아야합니다.
OpenID를 사용자의 기본 식별자로 만드십시오. OpenID 외에 사이트에서 유일한 이름의 식별자를 요구하지 않도록 합니다.
이유: 사용자는 이미 세계적으로 유일한 식별자를 가지고 있습니다. 만약 사이트에서만 사용하는 식별자를 또 만들어야한다면, 매우 귀찮고, 불필요한 절차라고 생각할 것입니다. 또 결과적으로 네임스페이스의 제약으로 원치 않는 식별자를 만들 수도 있습니다.
아이디에 핸들이나 이름을 추가하는 것을 허용은 하되, 요구하지는 마십시오.
사용자로 하여금 아이디에 해당하는 원하는 이름(실제 이름이나, 별명 등)을 선택하여 아이디 옆에 나타나게 할 수 있습니다. 이런 이름은 항상 검증된 OpenID 옆에 나타나므로, 유일하게 구별 될 필요는 없습니다. 포럼의 글을 예로 들자면,
|
홍길동
gildong.example.com
|
마포대교 건너기 |
| 다른 한강의 다리들과 마찬가지로 마포대교도 인도가 있어서 건널 수 있습니다. 재밌는 것은 한 30분쯤 걸어야하는 그 다리 중간에는 무슨 공연 시설 같은 것이 있다는 것입니다. 공연까지 할 수 있을 정도는 아니고, 지나가는 길에 쉬어 갈 수 있는 계단식 전망대(?)가 있습니다. 가끔 춥지 않은 날이면, 여의도 공원을 나와서 마포대교를 건너 5호선 마포역에 바로 닿는 그 길을 걷는 것도 좋습니다. 마포역 근처에 편의점이 하나 있는데, 컵라면을 사서 나오면 작은 공원이 있어서 맛있게 먹을 수 있는 센스도 있지요. 언제 같이 건너 보시겠습니까? |
이런 접근은 OpenID와 연관되는 사용자 계정을 만드는 경우나, 댓글을 남기는 수준의 간단한 블로그 로그인에 모두 사용될 수 있습니다. 둘의 차이는 후자의 경우 저장하지 않으므로 매번 로그인때 마다 이름을 묻게 해야합니다.
구현에 따라서 사용자이름이 없을 때, 일관성을 유지하기 위해 적절한 기본값을 넣어 줄 수도 있습니다. 예를 들어, "http://frank.example.com/"가 OpenID라면, "frank [example.com]" 과 같은 이름을 만들어 낼 수 있습니다.
사이트에서는 유일한 식별자인 OpenID가 구별이 애매해지는 일이 없어야합니다. OpenID를 줄여서 표시하는 경우에 두 개의 OpenID가 완벽히 같아서는 안됩니다. 전체 URI가 표시되는 것이 어색한 경우, 적당히 줄여쓴는 ID를 링크로 만들고 그 타겟과 캡션을 전체 URI로 할 수 있습니다. [TODO: rel="..." 키워드를 OpenID 식별자로 정의하여 소프트웨어에서 알 수 있게 하는 것이 좋지 않을까요?]
이유: 사람들은 누군가에 대해 얘기할 때 URL보다 이름을 선호합니다. 대개의 경우 이름이 중복되는 것은 별 문제가 아니며, 문제가 되는 경우에는 OpenID URL이 문제를 해결할 수 있게됩니다. 그러나 이런 경우는 항상 옵션으로 제공해야합니다. 어떤 사람들은 자신의 이름이 다른 사람과 같은 것을 원하지 않을 수도 있고, 어떤 사용자들은 사람이 아닐 수도 있기 때문입니다.
