This proposal is to allow use of same token to access multiple
protected resource across different servers. At minimum making it
optional would help in wide variety of media delivery use cases.
Proposal details:
Exclude hostname and port number in normalized request string
creation. Another possible approach could be to allow modifications
of the subdomains as consistent with the name server RFC.
Background: Adobe Media Streaming (HTTP and RTMP) use cases.
Current Adobe's IPTV and web video services partners including large
media broadcasting companies, CDN services, and IPTV solutions vendors
all face the problem that multiple resources need to be used for
making a single web video experience.
In case of HTTP media streaming a single content delivery may comprise
of hundreds of individual http fragments served that are delivered
over multiple network connections using multiple media assets. In
addition, Advertising, DRM and License server API/interaction may also
be involved.
When dynamic streaming or multi-bit rate media is being streamed then
fragments from different versions of the asset are requested based on
real time network and client feedback. Client re-authorization can
result in high a latency and non-realtime system degrading the user
experience in wide variety of rich media solutions delivered over the
internet.
In several load balancing solutions like CENAME or request redirection
may modify server URI based on runtime considerations. Many CDN
workflows and global Internet services use such schemes. Having
mandatory hostname, which could have been modified, restricts use of
HTTP token obtained before the load balancing decision was made.
Example workflow
+---+ +---------------+
| C |--(A)------ credentials --------->| Authorization |
| l |<-(B)------ Access Token ---------| Server |
| i | +---------------+
| e |
| n | +---+ Access Token +---------------+
| t | | W |--(C)----- in HTTP header ------->| Protected |
| | | e |<-(D)------ API response ---------| Resource[0] |
| |->| b | +---------------+
| | | | Access Token +---------------+
| |<-| S |--(E)----- in HTTP header ------->| Protected |
| | | e |<-(F)------ API response ---------| Resource[i] |
| | | r | +---------------+
| | | V | Access Token +---------------+
| | | i |--(G)----- in HTTP header ------->| Protected |
| | | c |<-(H)------ API response ---------| Resource[N] |
| | | e | +---------------+
+---+ +---+
Figure 1.
In the above Figure 1, client uses a webservice which performs a single
authorization to obtain an opaque access token. It then uses the same access
token to request multiple protected resources without needing to re-authorize
every time a new resource is used.
C,D: Request for license to decrypt the HD content
E,F: Multiple requests for the media fragments for HD content
G,H: Change request for lower bit-rate content in case there is network
congestion or need for lower resources on client. This request may happen after
30 mins of the start of the rich media experience session.
Thanks,
Gaurav Rastogi
Adobe Systems
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
