Thanks Barry, We had to partially roll our own registration spec because there was no common one at the time. We did however partially base ours on the UMA one and now we have sever groups working on https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ based on implementation experience to produce a common way to do it.
I don't think this is the first spec to develop that way. It is a interesting discussion to have on how much negotiation should happen at each level. In some ways this contrasts the approach taken by GSSAPI vs SAML where in GSSAPI things are negotiated a a low lever and in SAML they are generally preconfigured in some out of band way. In part it may be the difference between something that is session oriented vs OAuth/SAML SSO that are using REST like bindings. Now in SAML as part of the spec there is saml-meta-data that is supported in some (not enough) implementations because it is not MTI (sone of us would like to change that). Part of the driving forces between the approaches is that when things are federated there needs to be some sort of trust model and that is hard to anticipate in the lower levels. I don't think it has to be completely one way or the other, but there will be resistance to duplicating things in lower elves that are likely to be duplicated anyway as part of the higher level trust model. In Connect we have the problem that the protocol needs to support simple social networks all the way to three letter agencies. Those have very different trust models and even preferred algorithms. We have struggled with the Mandatory to Deploy features for interoperability, Mandatory to Implement is not useful if it is not also mandatory to deploy. So in the case of token endpoint authentication by HTTP basic it is reasonable to say a OAuth library needs to support http basic, it is not reasonable to say that a deployer that needs SAML assertions signed with EC keys cross certified with the federal bridge has to deploy it. That is where we get into the area Stephen Farrell has been raising about MTI not being required to deploy. That is fine if we are trying to specify library functionality, however it may not help real interoperability for applications. We likely need to have both. I can see saying that MTI for a library calling itself compliant with the specs needs to implement a minimum number of algorithms and token types. That is probably an easy agreement to come to. Agreeing on what features can or should be negotiated at the lower level vs pushed down from the configuration of the application using them is the harder part. I look forward to the discussion. John B. On 2013-02-18, at 4:03 PM, Barry Leiba <barryle...@computer.org> wrote: > It seems like the scope of your criticism has more to do with RFC 6749 & RFC > 6750 overall, than the assertions drafts themselves. > > No, and I'm sorry if it came across that way. I mentioned the token-type > issue only by way of background. As it happens, I do think it was a mistake > to publish the oauth framework spec without a mechanism for > discovery/negotiation/communication of token types, but I'm not holding that > against this document at all. > > In OpenID Connect we implemented a discovery and registration layer for > clients to discover what the Authorization server supports. > > Great! I think that each use of the protocol shouldn't have to roll this on > its own, but it's good that OIDC did it. > > To acceve real interoperability these things need to be profiled or you need > a negotiation mechanism. > > We do agree on that; cool. > > Are you saying that Assertions needs a low level mechanism to negotiate > capabilities? > Many will argue that specs at a higher level like like Dynamic Client > Registration https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ are > better places to address these capability negotiations because as you point > out there is more to be negotiated than just assertions. > > I would be happy to have it done that way, but then I think that needs to > happen first, and this needs to refer to that (normatively) as the (or a) > mechanism that helps this interoperate. > > It has been stated by one of the WG chairs that some of us are anti > interoperability, so some of us may be a touch sensitive, around this, as it > is not the case. > > Yeh, we very much need to keep that kind of rhetoric and questioning of > motives out of the discussion. You won't hear it from me, certainly. Quite > the opposite: I'm quite confident that we all share the goal of developing > good specs from which interoperable implementations can be built. It's not a > question of anti-anything, but of disagreement about how to accomplish that. > > Barry >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
