1 / 7

RS-AS Communication

IETF86 OpenID Workshop. RS-AS Communication. Structured Access Token for Sharing Authorization Grant between a Resource Server and an Authorization Server draft-sakimura-oidc-structured-token-01. PEOFIAMP Project. 2013-03-10. Nat Sakimura Nomura Research Institute Boku Kihara

peri
Download Presentation

RS-AS Communication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF86 OpenID Workshop RS-AS Communication Structured Access Token for Sharing Authorization Grant between a Resource Server and an Authorization Server draft-sakimura-oidc-structured-token-01 PEOFIAMP Project 2013-03-10 Nat Sakimura Nomura Research Institute BokuKihara Kazuki Shimizu Lepidum

  2. About PEOFIAMP Project • Funded by Ministry of Internal Affairs and Communication in FY 2012 • Joint project of National Institute of Informatics, U.of Tokyo, U.of Kyoto, NRI • Project Partners • ※1 TERENA: Trans-European Research and Education Networking Associationhttp://www.terena.org/ • ※2 REFEDS: https://refeds.org/ • ※3 GEANT: Multi-gigabit european research and education network and associated serviceshttp://www.geant.net/ • ※4 eduGAIN: http://www.edugain.org/

  3. Problem Statement

  4. Assumption

  5. Introduced Structure • 3.1. "iss" (Issuer) • REQUIRED. the identifier of the authorization server that issues the access token. • 3.2. "sub" (Subject) • REQUIRED. The identifier of the entity whose claims are provided in exchange for the access token. The value of this claims needs to be shared between the authorization server and the resource server. • 3.3. "aud" (Audience) • REQUIRED. The identifier of the resource server that receives the access token and returns claims. • 3.4. "exp" (Expiration Time) • REQUIRED. The expiration time on or after which the JWT MUST NOT be accepted. The value is an integer of seconds from 1970-01-01T00:00:00Z.

  6. 3.5. "nbf" (Not Before) • OPTIONAL. The time before which the JWT MUST NOT be acceppted. The value is an integer of seconds from 1970- 01-01T00:00:00Z • 3.6. "iat" (Issued At) • OPTIONAL. The time at which the JWT was issued. The value is an integer of seconds from 1970-01-01T00:00:00Z. • 3.7. "claims" • OPTIONAL. The claims about the entity identified by the "sub" claim • 3.8. "azp" " (Authorized Presenter) • OPTIONAL the identifier of the party which is intended to use the access token and to request resources.

  7. Project Status • I-D created • http://tools.ietf.org/id/draft-sakimura-oidc-structured-tokenImplementation • Implementation • A sample implementation complete

More Related