As part of exercise to test the extensibility of OpenID Connect to other protocols than HTTP, we have created a custom scheme binding. This is still a rough sketch but should give you some ideas on what it is. It may seem to be a bit of stretch, but has a niche characteristics that it does not "leak" information to external OPs. There will be a companion RP side as well, which would be a more normal case.

1. Smartphone Native Application OP
OpenID Connect application URL scheme binding
@_nat
@eijima
IdCon #11 IDENTITY CONFERENCE
February 3, 2012

2. Entities
User Info
RP(Web Application)
(Client) Request Authorization
OP(Smartphone Native Application)
(Authorization Server, Resource Server)
Access Token
Authenticate User
User-Agent(Smartphone Native Application)
Request Service
Smartphone
End-User
(Resource Owner)

3. Application URL Scheme
• We can bind a Smartphone (iOS SDK, Android
SDK) native application to a custom URL
scheme.
• That scheme can be used to launch the
application from either a browser or from
another application on the Smartphone.

4. User Experience – Client(RP) Registration -
1. User accesses RP by User-Agent 2. OP app starts and returns “not registered” 4. OP application starts 5. OP application returns
Tap “Kantan-Login” button error via User-Agent. OP asks User for the consent successful response via
* RP requests authorization 3. RP requests client registration via User- of RP registration User-Agent
Agent 6. RP re-requests
authorization

5. User Experience – Authorization & UserInfo Request -
1. User accesses RP by User-Agent 2. OP app asks User for the 3. OP app returns Access Token 5. RP receives the Access Token
Tap “Kantan-Login” button consent of PII transmission to to RP via User-Agent User logs in RP
RP 4. RP sends Access Token to RP
and requests OP to transmit
UserInfo via User-Agent.

6. Protocol Design
• Only support Implicit Grant
– Client authentication
• client_id == FQDN of the Client (RP)
• client_secret is not used. The implicit grant type does not include client authentication.
• Request from RP to OP
– End point(request) URI := openid://path
• e.g.) openid://host/path?query
– Request parameters
• Smartphone applications can receive only request URL string from RP via User-agent.
– All requests require a redirect_uri (or response_uri) parameter. These URI must be HTTPS.
• All requests must be sent by one of the following three methods. (like an authorization request of the OpenID Connect
Standard)
– Simple Request Method
– Request Parameter Method
– Request File Method
• Response from OP to RP
– OP send response to redirect_uri(or response_uri) by http GET method via User-agent. Both successful and error response must be
fragment-encoded.
– RP returns a page including a javascript code. The javascript code read the fragment and post the fragment to RP.
• Open Issue
– How to generate user_id of the ID Token? The user_id must be unique and never reassigned identifier among all OP apps.

7. Authorization Request & Response Sequence
• http://www.websequencediagrams.com/?lz=cGFydGljaXBhbn
QgRW5kVXNlciBhcyB1CgANDFJQXG5DbGllbnQgYXMgcnAA
EA1Vc2VyQWcAFQd1YQAsDU9QXG5TbWFydHBob25lQXB
wIGFzIG9wCgpub3RlIGxlZnQgb2YgcnA6IFJlcXVlc3QgRmlsZ
SBNZXRob2QKCnJwLT51YTogcgAWB0F1dGhvcml6YXRpb2
5cbm9wZW5pZDovL2F1dGg_XG4AIAdfdHlwZT10b2tlblxuJm
MAgTMFX2lkPXJwLmNvbVxuJnJlZGlyZWN0X3VyaT1odHRw
czovLwAYBgBGBS9jYWxsYmFja1xuJnNjb3BlPQBkBlxuJm5v
bmNlPW4tMFM2X1d6QTJNagBLBQByBgA3GACBOAcKCnVh
LT5vcACBORcKCm9wLT5ycDogZmV0Y2gAgWwJZmlsZQpyc
C0ALQ4AEQUALQV1OiBhdXRoZW50aWNhdGUgJgCCJgljb2
5zZW50CnUANQcACAgAMQZhOiBBY2Nlc3MgVG9rZW4gaW
4gZnJhZ21lbgCDDwYAghoLXG4AggocI1xuYQBEBV8Agm8F
PWpIa1dFLi4uNUtGMFlcbiYAgwUFAIMPBkJlYXJlclxuAIIFBnJ
wOiAAghoWAIMaBgCDfAUAg3wGc2NyaXAAgjsHdWE6IHBhc
nNlAIEmCmJ5ABUNAFEIIHBvc3QAgVgOdG8gUlAAJQsAWQ
k&s=modern-blue

8. Authorization Request & Response
Steps – Case: Request File Method -
1. RP(Client) redirects the User-Agent on the End-User’s smartphone to Authorization Endpoint with
“request_uri” parameter.
– Authorization Endpoint URI is Application URL scheme:”openid”
openid://auth?request_uri=https://rp.com/auth/request
2. OP application on the End-User’s smartphone starts via Authorization Endpoint(= Application URL
scheme: “openid”)
3. OP application fetches the Request File from “request_uri”
4. RP returns the Request File
5. OP application authenticates the End-User and obtains the End-User Consent/Authorization.
6. OP returns a response to the RP’s “redirect_uri” via User-Agent. Response parameters must be
fragment-encoded.
– https://rp.com/auth/callback#access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer &id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZ
XJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0c
DpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1
G3liaTNOrfaeWYjuRCEPNXVtaazNQ &state=af0ifjsldkj
7. RP returns the script to the User-Agent.
8. The script runs in the User-Agent and posts the OP’s response(access_token, id_token etc.) to the RP.

9. UserInfo Request & Response Sequence
• http://www.websequencediagrams.com/?lz=cGFydGljaXBhbn
QgUlBcbkNsaWVudCBhcyBycAoAEQxVc2VyQWcAFQd1YQA
PDU9QXG5TbWFydHBob25lQXBwIGFzIG9wCgpub3RlIGxlZn
Qgb2YgcnA6IFJlcXVlc3QgRmlsZSBNZXRob2QKCnJwLT51YT
ogcgAWB1VzZXJJbmZvIHcvAAwIX3VyaSBcbm9wZW5pZDov
L3VzZXJpbmZvPwAVCz1odHRwczovL3JwLmNvbQAbCS8AU
QcKCnVhLT5vcAAGY29wLT5ycDogZmV0Y2gAgU8JZmlsZQp
ycC0Adw5maWxlXG574oCcYWNjZXNzX3Rva2Vu4oCdOiAiU
2xBVjMyaGtLRyIsIOKAnHNjaGVtYQAXBeKAnACCCAbigJ0A
FwVyZXNwb25zZV91cmkAGggAgXgaACYGfQCBJQZvcDogZ
W5jcnlwAIJvDlJQJ3MgcHVibGljIGtleQCBUgZ1YToAgxgKaW4
gZnJhZ21lbgCDXQYAeQtcbgBeICNKV1RfZW5jb2RlZF8Ag20I
AIMgBnJwOiAAgR0gAIQ0BQCENAZzY3JpcACDWgd1YTogc
GFyc2UAgRAWYnkAIQ0AYQggcG8AhG4MABwKAFsJAIUiBX
JwOiBkZQCCHA4&s=modern-blue

10. UserInfo Request & Response Messages
• UserInfo Request parameters
– The following parameters are defined in addition to what ware defined by the OpenID Connect Messages 1.0.
• response_uri
– A response URI where the response will be sent.
• request
– A JWT encoded Request Object. For Request Parameter Method.
• request_uri
– The URI of the Request File. For Request File Method.
• UserInfo Request Object
– The Request Object must be JWT encoded. It may be JWS signed and/or JWE encrypted.
– Sample JSON
• *“access_token”: "SlAV32hkKG", “schema”: “openid”, “response_uri”:
“https://example.com/userinfo/response”+
• UserInfo Response
– The response must be JWT that is JWS signed with OP’s key and JWE encrypted with RP’s key.
– Error response parameters
• …
• Security considerations
– Because of the security weaknesses associated with the URI method (see Section 4), including the high likelihood
that the URL containing the access token will be logged.
The Client SHOULD construct the request using the Request Parameter Method with JWE encrypted or the
Request File Method.

11. Dynamic Client Registration Request & Response Sequence
• http://www.websequencediagrams.com/?lz=cGFydGljaXBhb
nQgRW5kVXNlciBhcyB1CgANDFJQXG5DTGllbnQgYXMgcn
AAEA1Vc2VyQWcAFQd1YQAsDU9QXG5TbWFydHBob25l
QXBwIGFzIG9wCgpub3RlIGxlZnQgb2YgdTogUmVxdWVzd
CBGaWxlIE1ldGhvZApycC0-
dWE6IHIAFQdyZWdpc3Qgdy8ACghfdXJpXG5vcGVuaWQ6L
y8AGgY_ABILPWh0dHA6Ly9ycC5jb20AGgcvAEkHCnVhLT5
vcABKFnNwb25zZV91cmwAJjtvcC0-cnA6IGZldGNoAIE-
CWZpbGUKcnAtAG8OZmlsZSAobXVzdCBiZSBKV1Mgc2lnb
mVkIEpXVClcbnsidHlwZSI6ImFzc29jaWF0ZSIsXG4gInJlZGl
yZWMAggYFcyI6Imh0dHBzAIFoCmNhbGxiYWNrIixcbiJqd2tf
dXJsABQScHVibGljX2tleS5qdwAmBgCBdwtpAEUSAIJACQ
CCIQYifQCBZgVvcDogdmVyaWZ5IEpXUwCBeQV1AIM0Cm
NvbnNlbnQKdQCBcgcACAgAMggAg1cHUlAAMwYAg3MFAI
MABiBjbGllbnRfaWQgaW4gZnJhZ21lbnRcbgB3HiMALQk9A
IN5BgCDawVycDogAIEvHgCDFQZ1YTogc2NyaXAAhCEGd
WE6IHBhcnNlAHYJIGJ5ABUMcnA6IHBvc3QAgSELABcKAE
kJ&s=modern-blue

12. Dynamic Client Registration Request &
Response Messages
• Dynamic Client Registration Request parameters
– The following parameters are defined in addition to what ware defined by the OpenID Connect Dynamic Client Registration 1.0.
– response_uri
• REQUIRED. A response URI where the response will be sent.
– request
• A JWT encoded Request Object. For Request Parameter Method.
– request_uri
• The URI of the Request File. For Request File Method.
• Dynamic Client Registration Request Object
– Request Object must be JWT that is JWS signed with RP’s key.
– The JWK which the “jwk_url” parameter in the JSON points must be same as the JWK which the “jku” parameter in the JWS header points.
– Sample JSON
• * “type”: ”client_associate”,
“redirect_uris”: “https://example.com/callback”,
“logo_url”: “https://example.com/logo.png”,
“jwk_url”=“https://example.com/public_key.jwk”,
“userinfo_encrypted_response_algs”: “RSA1_5 A128CBC”
“response_uri”: “https://example.com/regist/response” +
• Dynamic Client Registration Response parameters
– client_id == FQDN of the Client (FQDN of “response_uri”?)
– client_secret is not used. The implicit grant type does not include client authentication.
– Sample response: https://example.com/regist/response#client_id=example.com
• Open issues
– When a different business entity shares the same FQDN(==client_id), e.g. users of same hosting service, one registration makes it unable to
perform registration of another side.

13. Open Isuue
Client Registration Authority – Embedded in OP
application vs Central RA
• Central Client Registration Authority
– Advantage
• Clients(RPs) register their parameters to the Central Client Registration
Authority.
There is no necessity of changing current draft of the OpenID Connect
Dynamic Client Registration specification.
• There is no restriction in the value of client_id.
• The End-User does not need to care about the Client Registration.
– But
• OP application must query the Central RA to get the registration
information of Clients(RPs).
• Must manage the Central RA

14. IdCon #11 IDENTITY CONFERENCE
Thanks!