Re: [OAUTH-WG] OAuth WG Re-Chartering

[John Bradley <[e-mail]>]

In Connect it is mostly the client that introspects the token, though we do use JWT to keep things stateless.

As we move to more complex environments where clients are getting multiple tokens from a AS for RS and those RS are decoupled from the AS,  we need to talk about JWT and introspection.

They will become blocking issues for interoperability at larger scale.

John B.
On 2012-03-15, at 7:04 AM, Paul Madsen wrote:

> To Eran's point about the relevance of RS-AS standardization in internal vs external deployments, many of our customers are using our AS to issue tokens to their API clients, but an API management solution (from different vendor) to front their APIs. 
> 
> The API management soln becomes the RS and must validate the tokens it sees against our AS. 
> 
> Until OAuth standardizes this piece, we have to convince such partners to use our (necessarily proprietary) endpoint (or support whatever mechanism they expect).
> 
> paul
> 
> On 3/15/12 1:19 AM, Eran Hammer wrote:
>> 
>> 
>>> -----Original Message-----
>>> From: Richer, Justin P. [mailto:[e-mail]]
>>> Sent: Wednesday, March 14, 2012 7:51 PM
>>> [...] the AS-PR connection is a real and present known
>>> gap introduced in OAuth2 (since OAuth1 didn't even think of them as
>>> separate entities) and *somebody* should be trying to codify the best ways
>>> to fill that gap and I think this is a good place to do it.
>> I'm not sure this is an issue for more existing implementations given that it is just an internal implementation detail. It becomes more of a use case when you have different entities managing the different roles. I'm not objecting to this line of work, but I we do need a proposal and it should be based on something more than just ideas (e.g. some deployment experience). One of the benefit of starting off a draft and not just ideas is that it shows real interest and traction.
>>  
>>> Along those lines, I don't think that SWD really belongs in the OAuth group
>>> either *except* for the fact that there's a Discovery mandate below that
>>> nobody's contesting. It's arguable that this simply covers the WWW-
>>> Authenticate header and its value in different contexts, but we all know this
>>> is incomplete discovery at best.
>> Discovery is a very wide topic. The only discovery item proposed I the dynamic client registration proposal. It is fine to discuss potential discovery tools in this context, but we should not be the primary source of innovation in the space. So we're in agreement that SWD doesn't belong here. Nor does WebFinger which is working on similar problems.
>> 
>> The ideal scenario would be to get traction on these general purpose discovery mechanisms elsewhere, and revisit this when the working group is discussing the dynamic client registration proposal. IOW, we may end up discussing and contributing to an APPS area discovery work to ensure our needs are supported, but not publish such documents in the WG.
>> 
>>> JWT also doesn't feel like it really belongs
>>> here, but since JOSE won't have it, it's a fairly important orphan that's already
>>> seeing deployment experience.
>> I don't have strong opinions on this, mostly because I understand it to be fairly finished. If the WG will need to spend a few months discussing it, I will have to reconsider.
>> 
>>> Add to all of this that I have two other drafts that I'd like to see dusted off
>>> and moved forward through some process -- alternate encoding (XML and
>>> Form parameters) from the token endpoint, and the UX/dynreg related
>>> "instance information" draft. I'll have versions of both of these uploaded
>>> once the IETF tracker takes the locks off at the end of the month. 
>> I think the XML draft is simple enough to include. I've supported it in the last round. I think the UX work is actually really important if someone is willing to take the lead on that and do the work.
>> 
>>> Neither of
>>> these saw much WG feedback or support before, though, so I'm open to
>>> suggestions of what a better home for them might be, if there is one. Or
>>> maybe we should make a new group for all the orphaned open web specs?
>> I think many people here don't fully understand the ways the IETF works. While working groups are the main venue for collaboration, there is a lot of work done on an Individual Submission basis (more than half?). This means a specification is created and finalized outside an official WG and without a charter.
>> 
>> The general mechanism (at least as used pretty effectively by me for a handful of published RFCs) is to find the right mailing list (e.g. HTTP for Link relations, Apps Discuss for host-meta and well-known, OAuth for OAuth 1.0) and support from an Area Director. You also need to fine a document shepherd  to help review and help with the "paperwork".
>> 
>> The way this works is that you can write a specification, discuss it on the WG list, and when you feel it is ready, ask the sponsoring AD for IETF Last Call. The AD might decide this is better suited to go through the full WG process, or feel that the document is simple and narrow enough to skip it. It is also possible that some of this work will be discussed on this list, but sponsored by an APPS area AD (e.g. the XML extension is a perfect example for something that is really not a security protocol component). So you have options.
>> 
>> IOW, getting your draft onto the charter is actually not always the best option for a straight-forward but low priority/interest work. The individual submission track might be better for you and the WG. You might want to reach out to one of the ADs or Chairs and discuss these options.
>> 
>> EH
>> 
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth