OAuth그룹에서의 최근 근황을 적어봅니다.
이슈 1.
Yahoo가 주최하는 OAuth Summit 2008이 6월 26일 Santa Clara, CA에서 열릴 예정이라고 합니다.
이번 행사에서는 OAuth 프로토토콜, 확장성, OAuth 구현을 했던 경험 공유, 그리고 개발자들 간의 교류를 목적으로 합니다. 적어도 OAuth 스팩에 대한 이해를 가지고 참가해야 한다고 합니다.^^
이슈 2.
OAuth Core 1.0 Final이 2007년 12월 4일에 공표된 이후로, 커뮤니티에는 많은 피드백과 구현과정에서 추가적으로 필요한 제안들이 많이 올라왔었습니다. 그 이유인즉, 실제 OAuth Core 1.0에서 제시하는 바로는 실제 서비스 프로바이더와 컨수머간에 생길수 있는 여러가지고 요구사항을 충분히 수렴하지는 못했던 것이라고 생각합니다. 실제로 OAuth 컨수머와 프로바이더를 구현해보면서 앞으로 OAuth Core의 확장이 필요하다고 생각했었는데, 최근 OAuth그룹에서 Eran Hammer - Lahav가 제안한 OAuth Core 1.1 을 한번 정리해볼까 합니다.
- '리소스'와 '접근 요청', 그리고 '접근'이 가장 일반적인 질문이라고 할 수 있다. Core 1.0에는 각각의 프로바이더들이 개발해나가고자 하는 것을 배제하고 명세되어 있다.
- 명세는 다른 언어로 번역되야 하고, 더 많은 예제가 제공되어야 하며, Appendix A에 있는 전체 예제를 문서의 제일 위로 위치시켜서 가독성을 향상시킬 수 있겠다. 일반적으로 튜토리얼에서 시작하여 레퍼런스로 옮겨가기 때문.
- Core 1.0은 크리티컬한 상호운영에 대한 확실한 에러처리에 대해 부족하다.
- 확장성과 보안 부분에서 대규모 프로바이더에게 더 좋은 지원을 하기 위하여 명세를 수정해야 한다.
추가적으로, 다음과 같은 기능(feature)들이 요구되었다.
- HTTP Body signature : 페이로드(payload)데이터를 sign하는 방법 제공
- 언어 지원 : 메인 스팩에 extension을 포함.
- 2개의 플로우 : 어떻게 2개의 시나리오가 동일한 시그네이쳐 메소드를 사용하여 동작해야만 하는지에 대해 Core에 명확한 정의를 추가.(?)
다른 작은 제안들로는,
- RSA와, token secret을 제외하는 두가지 메소드들간의 보안상의 차이에 대해서 명확하게 해야함
- consumer 에 명시되어야 하는 nonce와 timestamp언어뿐 아니라 token에 명시되어야 하는 nonce와 timestamp언어 대해서도 명확히 해야 함.
Core, Extensions 어디에 포함시켜야 하는가?,
Core 1.0을 개발하면서 범위에 대해서, 그리고 그것이 core 프로토콜에 포함되어야 하는 것인지, extension에 속해야 하는 것인지에 대하여 긴 토론을 하였다. 위에 있는 모든 것이 core 명세에 포함되어야 하는 것은 아니지만, 우리가 작업한 것들이 가능한한 문서에 포함시켜야 하는 많은 이유가 있다. 현실적으로, 더 중요한 사항은 이해를 시켜주고 지원을 해주는 것이다.
Core 1.1의 범위 제안
- 에러 리포팅 : error code(URI 형식)와 사람이 읽을 수 있는 텍스트, 이 두가지 파라미터를 추가해야 한다. 일반적인 프로토콜 에러에 대한 코드의 집합을 정의해야 한다. 확장하기 쉽도록 스트링이나 숫자를 쓰는것 보다는 에러코드를 위하여 URI를 사용하는 것이 좋겠다.
- 2개의 플로우 : consumer key와 secret을 사용할때만, token과 token secret을 비워두는 경우, OAuth signature string을 어떻게 명시해야 하는지에 대한 정의
- HTTP Body signature : body의 시그내처를 지원할 새로운 파라미터 추가.(non-multi-part-bodies에 관점에 제한하여). 파라미터는 일반적인 플로우를 사용하여 인증을 받아냄.
- 언어 지원 : 스팩에 언어 제안 포함
- RSA 보안과 nonce limitation에 대한 언어 수정
- 위에서 제안한 것을 기반으로 한 토큰 어트리뷰트에 대한 뼈대를 추가. 기본적으로 키/밸류 한쌍의 파라미터. 서비스프로바이더가 명세할 수 있는 것과 최소한의 키들의 집합 정의
references
- http://groups.google.com/group/oauth/t/808e4a98193de671?hl=en
- http://groups.google.com/group/oauth/t/b4d71abb0ac81e60?hl=en
이슈 1.
Yahoo가 주최하는 OAuth Summit 2008이 6월 26일 Santa Clara, CA에서 열릴 예정이라고 합니다.
이번 행사에서는 OAuth 프로토토콜, 확장성, OAuth 구현을 했던 경험 공유, 그리고 개발자들 간의 교류를 목적으로 합니다. 적어도 OAuth 스팩에 대한 이해를 가지고 참가해야 한다고 합니다.^^
이슈 2.
OAuth Core 1.0 Final이 2007년 12월 4일에 공표된 이후로, 커뮤니티에는 많은 피드백과 구현과정에서 추가적으로 필요한 제안들이 많이 올라왔었습니다. 그 이유인즉, 실제 OAuth Core 1.0에서 제시하는 바로는 실제 서비스 프로바이더와 컨수머간에 생길수 있는 여러가지고 요구사항을 충분히 수렴하지는 못했던 것이라고 생각합니다. 실제로 OAuth 컨수머와 프로바이더를 구현해보면서 앞으로 OAuth Core의 확장이 필요하다고 생각했었는데, 최근 OAuth그룹에서 Eran Hammer - Lahav가 제안한 OAuth Core 1.1 을 한번 정리해볼까 합니다.
- '리소스'와 '접근 요청', 그리고 '접근'이 가장 일반적인 질문이라고 할 수 있다. Core 1.0에는 각각의 프로바이더들이 개발해나가고자 하는 것을 배제하고 명세되어 있다.
- 명세는 다른 언어로 번역되야 하고, 더 많은 예제가 제공되어야 하며, Appendix A에 있는 전체 예제를 문서의 제일 위로 위치시켜서 가독성을 향상시킬 수 있겠다. 일반적으로 튜토리얼에서 시작하여 레퍼런스로 옮겨가기 때문.
- Core 1.0은 크리티컬한 상호운영에 대한 확실한 에러처리에 대해 부족하다.
- 확장성과 보안 부분에서 대규모 프로바이더에게 더 좋은 지원을 하기 위하여 명세를 수정해야 한다.
추가적으로, 다음과 같은 기능(feature)들이 요구되었다.
- HTTP Body signature : 페이로드(payload)데이터를 sign하는 방법 제공
- 언어 지원 : 메인 스팩에 extension을 포함.
- 2개의 플로우 : 어떻게 2개의 시나리오가 동일한 시그네이쳐 메소드를 사용하여 동작해야만 하는지에 대해 Core에 명확한 정의를 추가.(?)
다른 작은 제안들로는,
- RSA와, token secret을 제외하는 두가지 메소드들간의 보안상의 차이에 대해서 명확하게 해야함
- consumer 에 명시되어야 하는 nonce와 timestamp언어뿐 아니라 token에 명시되어야 하는 nonce와 timestamp언어 대해서도 명확히 해야 함.
Core, Extensions 어디에 포함시켜야 하는가?,
Core 1.0을 개발하면서 범위에 대해서, 그리고 그것이 core 프로토콜에 포함되어야 하는 것인지, extension에 속해야 하는 것인지에 대하여 긴 토론을 하였다. 위에 있는 모든 것이 core 명세에 포함되어야 하는 것은 아니지만, 우리가 작업한 것들이 가능한한 문서에 포함시켜야 하는 많은 이유가 있다. 현실적으로, 더 중요한 사항은 이해를 시켜주고 지원을 해주는 것이다.
Core 1.1의 범위 제안
- 에러 리포팅 : error code(URI 형식)와 사람이 읽을 수 있는 텍스트, 이 두가지 파라미터를 추가해야 한다. 일반적인 프로토콜 에러에 대한 코드의 집합을 정의해야 한다. 확장하기 쉽도록 스트링이나 숫자를 쓰는것 보다는 에러코드를 위하여 URI를 사용하는 것이 좋겠다.
- 2개의 플로우 : consumer key와 secret을 사용할때만, token과 token secret을 비워두는 경우, OAuth signature string을 어떻게 명시해야 하는지에 대한 정의
- HTTP Body signature : body의 시그내처를 지원할 새로운 파라미터 추가.(non-multi-part-bodies에 관점에 제한하여). 파라미터는 일반적인 플로우를 사용하여 인증을 받아냄.
- 언어 지원 : 스팩에 언어 제안 포함
- RSA 보안과 nonce limitation에 대한 언어 수정
- 위에서 제안한 것을 기반으로 한 토큰 어트리뷰트에 대한 뼈대를 추가. 기본적으로 키/밸류 한쌍의 파라미터. 서비스프로바이더가 명세할 수 있는 것과 최소한의 키들의 집합 정의
references
- http://groups.google.com/group/oauth/t/808e4a98193de671?hl=en
- http://groups.google.com/group/oauth/t/b4d71abb0ac81e60?hl=en
