Phil, neither is Connect an authentication mechanism, it (and SAML,
WS-fed etc) is also a 'method for providing end-user authentication
information to client applications'
We don't need a Connect--
paul
On 5/14/14, 1:29 PM, Phil Hunt wrote:
This is not an authentication mechanism - it is a method for providing
end-user authentication information to client applications. I will
publish a revised draft shortly.
Phil
@independentid
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On May 14, 2014, at 10:23 AM, George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>> wrote:
I also would like to see the WG not focus on another authentication
mechanism and instead look at work like Brian suggested.
Thanks,
George
On 5/14/14, 11:41 AM, Chuck Mortimore wrote:
Agree with Brian and Justin here. Work is already covered in Connect
- cmort
On May 14, 2014, at 8:39 AM, Justin Richer <jric...@mit.edu
<mailto:jric...@mit.edu>> wrote:
I agree with Brian and object to the Authentication work item. I
think there's limited interest and utility in such a draft,
especially now that OpenID Connect has been published and its core
authentication capabilities are identical to what was called for in
the other draft a year ago (a similarity, I'll add, which was noted
at the time).
--- Justin
On May 14, 2014, at 8:24 AM, Brian Campbell
<bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com>> wrote:
I would object to 'OAuth Authentication' being picked up by the WG
as a work item. The starting point draft has expired and it hasn't
really been discusses since Berlin nearly a year ago. As I
recall, there was only very limited interest in it even then. I
also don't believe it fits well with the WG charter.
I would suggest the WG consider picking up 'OAuth Symmetric Proof
of Possession for Code Extension' for which there is an excellent
starting point of
http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a
relativity simple security enhancement which addresses problems
currently being encountered in deployments of native clients.
On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig
<hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,
you might have seen that we pushed the assertion documents and
the JWT
documents to the IESG today. We have also updated the
milestones on the
OAuth WG page.
This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for
the OAuth
security mechanisms to use the proof-of-possession terminology.
We also expect an updated version of the dynamic client
registration
spec incorporating last call feedback within about 2 weeks.
We would like you to think about adding the following
milestones to the
charter as part of the re-chartering effort:
-----
Nov 2014 Submit 'Token introspection' to the IESG for
consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>
Jan 2015 Submit 'OAuth Authentication' to the IESG for
consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>
Jan 2015 Submit 'Token Exchange' to the IESG for consideration
as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>
-----
We also updated the charter text to reflect the current
situation. Here
is the proposed text:
-----
Charter for 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 share his or her photo-sharing sites' long-term
credential with
the printing site.
The OAuth 2.0 protocol suite encompasses
* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
(JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.
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 work that remains
to be
completed on proof-of-possession and token exchange.
The ongoing standardization effort within the OAuth working
group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection
service and
standards for additional security of OAuth requests.
-----
Feedback appreciated.
Ciao
Hannes & Derek
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Ping Identity logo <https://www.pingidentity.com/>
Brian Campbell
Portfolio Architect
@ bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com>
phone +1 720.317.2061
Connect with us...
twitter logo <https://twitter.com/pingidentity> youtube logo
<https://www.youtube.com/user/PingIdentityTV> LinkedIn logo
<https://www.linkedin.com/company/21870> Facebook logo
<https://www.facebook.com/pingidentitypage> Google+ logo
<https://plus.google.com/u/0/114266977739397708540> slideshare
logo <http://www.slideshare.net/PingIdentity> flipboard logo
<http://flip.it/vjBF7> rss feed icon
<https://www.pingidentity.com/blogs/>
Register for Cloud Identity Summit 2014 | Modern Identity
Revolution | 19--23 July, 2014 | Monterey, CA
<https://www.cloudidentitysummit.com/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
<XeC.html> <http://connect.me/gffletch>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
