Hi Paul,
for me, your proposal looks like the natural counterpart of JWT, as it
standardizes the way to implement handle-based token designs (in
contrast to self-contained tokens).
therefore +1 from my side.
regards,
Torsten.
Am 15.03.2012 11:35, schrieb Paul Madsen:
+1 to defining RS-AS interactions. We've implemented such a 'token
introspection' endpoint in our AS and I'm be happy to no longer need
to explain to customers/partners why it's not part of the standard.
As input, an (incomplete) spec for our endpoint enclosed. (we modeled
the verification as a new grant type, leveraging as much as possible
the existing token endpoint API)
Wrt the 5 item limit
1) is this an arbitrary #? if people sign up to work on more items,
could it be extended?
2) the use cases document seems already well progressed (and
informational). Need it count against the 5?
paul
On 3/14/12 5:53 PM, Richer, Justin P. wrote:
Methods of connecting the PR to the AS are something that several groups have
invented outside of the OAuth WG, and I think we should try to pull some of
this work together. OAuth2 gives us a logical separation of the concerns but
not a way to knit them back together.
Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID,
and several "token introspection" endpoints in various implementations.
-- Justin
On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:
So, here is a proposal:
-------
Web Authorization Protocol (oauth)
Description of Working Group
The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user
sharing his or her photo-sharing sites' long-term credential with the
printing site.
The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server,
* a protocol for obtaining authorization tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these authorization tokens to protected
resources for access to a resource, and
* consequently for sharing data in a security and privacy respective way.
In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result
is available as a stand-alone document offering guidance for audiences
beyond the community of protocol implementers.
The working group also developed security schemes for presenting authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access
authentication specification.
OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token
with
the SAML 2.0 bearer assertion profile. This offers interworking with existing
identity management solutions, in particular SAML based deployments.
OAuth has enjoyed widespread adoption by the Internet application service
provider
community. To build on this success we aim for nothing more than to make OAuth
the
authorization framework of choice for any Internet protocol. Consequently, the
ongoing standardization effort within the OAuth working group is focused on
enhancing interoperability of OAuth deployments. While the core OAuth
specification
truly is an important building block it relies on other specifications in order
to
claim completeness. Luckily, these components already exist and have been
deployed
on the Internet. Through the IETF standards process they will be improved in
quality and will undergo a rigorous review process.
Goals and Milestones
[Editor's Note: Here are the completed items.]
Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a
working group item
Done Submit 'HTTP Authentication: MAC Authentication' as a working group item
Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for
consideration as a Proposed Standard
Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for
consideration as a Proposed Standard
[Editor's Note: Finishing existing work. Double-check the proposed dates - are
they realistic?]
Jun. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG
for consideration as a Proposed Standard
Apr. 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to
the IESG for consideration as a Proposed Standard
Apr. 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration
as a Proposed Standard
Apr. 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for
consideration as a Proposed Standard
May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the
IESG for consideration as an Informational RFC
[Editor's Note: New work for the group. 5 items maximum! ]
Aug. 2012 Submit 'Token Revocation' to the IESG for consideration as a
Proposed Standard
[Starting point for the work will
behttp://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for consideration as a
Proposed Standard
[Starting point for the work will
behttp://tools.ietf.org/html/draft-jones-json-web-token]
Nov. 2012 Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0'
to the IESG for consideration as a Proposed Standard
[Starting point for the work will
behttp://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
Jan. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG
for consideration as a Proposed Standard
[Starting point for the work will
behttp://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
Sep. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an
Informational RFC
[Starting point for the work will
behttp://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
